From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129785 invoked by alias); 22 Aug 2017 13:53:57 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 129752 invoked by uid 89); 22 Aug 2017 13:53:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f171.google.com Received: from mail-wr0-f171.google.com (HELO mail-wr0-f171.google.com) (209.85.128.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 Aug 2017 13:53:53 +0000 Received: by mail-wr0-f171.google.com with SMTP id k46so51507010wre.2 for ; Tue, 22 Aug 2017 06:53:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version:content-transfer-encoding; bh=5Zz60GeOKSaeaLSkZpGmJLQpjJgnzQMMly6PGjXdGNo=; b=i17aZtIyLRgZ5d+eWfUBCC5gRoUlGh75m1S0oC4qXBc4Hgc9114S+09yMgtOIQ5yIl oSFL2R+gQD00bTbwr3PQcXuQeNVsMhnRJ1/vOdtYZhrJIEIYybmRgCTsNcDUu7gPa3vZ LzTZggT96PSsXw1KVkuL9v8Y25HA+Bx+TzH/u50WTBUSGyXTG4eZ5wqYJtSHryPK9jLI c3QnAwCMb/m5or0JSqaWRNpLw61zw1P5bQSd8yu5LY6avwq00mnUHZpBFaNGxwBgt9jX jdtCZ/wT9klnU/fm2vBIIl/A00+C4If1Tz5DEuJcWmS1afVa4ZwX9TN5w6zvOlrV+RuJ 2gvg== X-Gm-Message-State: AHYfb5jtmuoisJPN5LrnYo6D8yN7HqoO9WdVHDvvZOq3hwzgE0SwwJYM d17rVPp3jfk3uZVe X-Received: by 10.28.9.72 with SMTP id 69mr448242wmj.154.1503410031187; Tue, 22 Aug 2017 06:53:51 -0700 (PDT) Received: from zen.linaro.local ([81.128.185.34]) by smtp.gmail.com with ESMTPSA id 76sm9490167wmm.39.2017.08.22.06.53.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 06:53:50 -0700 (PDT) Received: from zen (localhost [127.0.0.1]) by zen.linaro.local (Postfix) with ESMTPS id C06763E0049; Tue, 22 Aug 2017 14:53:49 +0100 (BST) References: <1502280338-23002-1-git-send-email-Dave.Martin@arm.com> <1502280338-23002-10-git-send-email-Dave.Martin@arm.com> <87y3qb52ez.fsf@linaro.org> <20170822111705.GT6321@e103592.cambridge.arm.com> User-agent: mu4e 0.9.19; emacs 25.2.50.3 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Dave Martin Cc: linux-arch@vger.kernel.org, libc-alpha@sourceware.org, Ard Biesheuvel , Szabolcs Nagy , gdb@sourceware.org, Yao Qi , Alan Hayward , Will Deacon , Richard Sandiford , Catalin Marinas , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 09/27] arm64/sve: Signal frame and context structure definition In-reply-to: <20170822111705.GT6321@e103592.cambridge.arm.com> Date: Tue, 22 Aug 2017 13:53:00 -0000 Message-ID: <87tw0z4sk2.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00044.txt.bz2 Dave Martin writes: > On Tue, Aug 22, 2017 at 11:22:44AM +0100, Alex Bennée wrote: >> >> Dave Martin writes: >> >> > This patch defines the representation that will be used for the SVE >> > register state in the signal frame, and implements support for >> > saving and restoring the SVE registers around signals. >> > >> > The same layout will also be used for the in-kernel task state. >> > >> > Due to the variability of the SVE vector length, it is not possible >> > to define a fixed C struct to describe all the registers. Instead, >> > Macros are defined in sigcontext.h to facilitate access to the >> > parts of the structure. >> > >> > Signed-off-by: Dave Martin >> > --- >> > arch/arm64/include/uapi/asm/sigcontext.h | 113 ++++++++++++++++++++++++++++++- >> > 1 file changed, 112 insertions(+), 1 deletion(-) >> > >> > diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h >> > index f0a76b9..0533bdf 100644 >> > --- a/arch/arm64/include/uapi/asm/sigcontext.h >> > +++ b/arch/arm64/include/uapi/asm/sigcontext.h >> > @@ -16,6 +16,8 @@ >> > #ifndef _UAPI__ASM_SIGCONTEXT_H >> > #define _UAPI__ASM_SIGCONTEXT_H >> > >> > +#ifndef __ASSEMBLY__ >> > + >> > #include >> > >> > /* >> > @@ -41,10 +43,11 @@ struct sigcontext { >> > * >> > * 0x210 fpsimd_context >> > * 0x10 esr_context >> > + * 0x8a0 sve_context (vl <= 64) (optional) >> > * 0x20 extra_context (optional) >> > * 0x10 terminator (null _aarch64_ctx) >> > * >> > - * 0xdb0 (reserved for future allocation) >> > + * 0x510 (reserved for future allocation) >> > * >> > * New records that can exceed this space need to be opt-in for userspace, so >> > * that an expanded signal frame is not generated unexpectedly. The mechanism >> > @@ -116,4 +119,112 @@ struct extra_context { >> > __u32 __reserved[3]; >> > }; >> > >> > +#define SVE_MAGIC 0x53564501 >> > + >> > +struct sve_context { >> > + struct _aarch64_ctx head; >> > + __u16 vl; >> > + __u16 __reserved[3]; >> > +}; >> > + >> > +#endif /* !__ASSEMBLY__ */ >> > + >> > +/* >> > + * The SVE architecture leaves space for future expansion of the >> > + * vector length beyond its initial architectural limit of 2048 bits >> > + * (16 quadwords). >> > + */ >> > +#define SVE_VQ_MIN 1 >> > +#define SVE_VQ_MAX 0x200 >> > + >> > +#define SVE_VL_MIN (SVE_VQ_MIN * 0x10) >> > +#define SVE_VL_MAX (SVE_VQ_MAX * 0x10) >> > + >> > +#define SVE_NUM_ZREGS 32 >> > +#define SVE_NUM_PREGS 16 >> > + >> > +#define sve_vl_valid(vl) \ >> > + ((vl) % 0x10 == 0 && (vl) >= SVE_VL_MIN && (vl) <= SVE_VL_MAX) >> > +#define sve_vq_from_vl(vl) ((vl) / 0x10) >> > +#define sve_vl_from_vq(vq) ((vq) * 0x10) >> >> I got a little confused first time through over what VQ and VL where. >> Maybe it would make sense to expand a little more from first principles? >> >> /* >> * The SVE architecture defines vector registers as a multiple of 128 >> * bit quadwords. The current architectural limit is 2048 bits (16 >> * quadwords) but there is room for future expansion beyond that. >> */ > > This comes up in several places and so I didn't want to comment it > repeatedly everywhere. > > Instead, I wrote up something in section 2 (Vector length terminology) > of Documentation/arm64/sve.txt -- see patch 25. Can you take a look and > see whether that's adequate? Ahh, I hadn't got to that yet. I'm unsure to the order the kernel likes to put things but I like to put design documents at the front of the patch queue as they are useful primers and saves you having to patch a: modified arch/arm64/include/uapi/asm/sigcontext.h @@ -132,19 +132,24 @@ struct sve_context { /* * The SVE architecture leaves space for future expansion of the * vector length beyond its initial architectural limit of 2048 bits - * (16 quadwords). + * (16 quadwords). See Documentation/arm64/sve.txt for a summary of + * the terminology of Vector Quads (VQ) and Vector Lengths (VL). */ + +#define SVE_VQ_BITS 128 /* 128 bits in one quadword */ +#define SVE_VQ_BYTES (SVE_VQ_BITS / 8) + #define SVE_VQ_MIN 1 #define SVE_VQ_MAX 0x200 -#define SVE_VL_MIN (SVE_VQ_MIN * 0x10) -#define SVE_VL_MAX (SVE_VQ_MAX * 0x10) +#define SVE_VL_MIN (SVE_VQ_MIN * SVE_VQ_BYTES) +#define SVE_VL_MAX (SVE_VQ_MAX * SVE_VQ_BYTES) #define SVE_NUM_ZREGS 32 #define SVE_NUM_PREGS 16 #define sve_vl_valid(vl) \ - ((vl) % 0x10 == 0 && (vl) >= SVE_VL_MIN && (vl) <= SVE_VL_MAX) + ((vl) % SVE_VQ_BYTES == 0 && (vl) >= SVE_VL_MIN && (vl) <= SVE_VL_MAX) #define sve_vq_from_vl(vl) ((vl) / 0x10) #define sve_vl_from_vq(vq) ((vq) * 0x10) > > [...] > > Cheers > ---Dave -- Alex Bennée