From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15184 invoked by alias); 23 Aug 2017 17:30:01 -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 15120 invoked by uid 89); 23 Aug 2017 17:29:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=18pm, misuse X-Spam-User: qpsmtpd, 2 recipients X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Aug 2017 17:29:58 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5412715AD; Wed, 23 Aug 2017 10:29:57 -0700 (PDT) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1888E3F3E1; Wed, 23 Aug 2017 10:29:54 -0700 (PDT) Date: Wed, 23 Aug 2017 17:30:00 -0000 From: Dave Martin To: Alex =?iso-8859-1?Q?Benn=E9e?= 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 14/27] arm64/sve: Backend logic for setting the vector length Message-ID: <20170823172952.GB6321@e103592.cambridge.arm.com> References: <1502280338-23002-1-git-send-email-Dave.Martin@arm.com> <1502280338-23002-15-git-send-email-Dave.Martin@arm.com> <87shgi9u4h.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87shgi9u4h.fsf@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2017-08/txt/msg00066.txt.bz2 On Wed, Aug 23, 2017 at 04:33:18PM +0100, Alex Bennée wrote: > > Dave Martin writes: > > > This patch implements the core logic for changing a task's vector > > length on request from userspace. This will be used by the ptrace > > and prctl frontends that are implemented in later patches. > > > > The SVE architecture permits, but does not require, implementations > > to support vector lengths that are not a power of two. To handle > > this, logic is added to check a requested vector length against a > > possibly sparse bitmap of available vector lengths at runtime, so > > that the best supported value can be chosen. > > > > Signed-off-by: Dave Martin > > --- > > arch/arm64/include/asm/fpsimd.h | 6 +++ > > arch/arm64/kernel/fpsimd.c | 116 ++++++++++++++++++++++++++++++++++++++++ > > include/uapi/linux/prctl.h | 5 ++ > > 3 files changed, 127 insertions(+) > > > > diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h > > index 7efd04e..39b26d2 100644 > > --- a/arch/arm64/include/asm/fpsimd.h > > +++ b/arch/arm64/include/asm/fpsimd.h > > @@ -70,11 +70,15 @@ extern void fpsimd_update_current_state(struct fpsimd_state *state); > > > > extern void fpsimd_flush_task_state(struct task_struct *target); > > > > +#define SVE_VL_ARCH_MAX 0x100 > > + > > Hmm this isn't the same as SVE_VL_MAX. Why aren't we using that? There should probably be a comment on this. SVE vector-length agnostic software needs to be able to assume that VL <= 256 (the SVE maximum), because some instructions won't work as expected if this is not the case, particularly TBL, where in a larger vector there's no guarantee that a vector index (which might be as small as a byte) can index a vector element (of which there could be >256). I really don't want to expose SVE_VL_ARCH_MAX to userspace, so that people are not tempted to design data structures and protocols that can't handle up to SVE_VL_MAX. Exposing both together seemed to carry a high risk of confusion and misuse. Instead, I silently clamp to an SVE-compatible length (i.e., SVE_VL_ARCH_MAX) in sve_set_vector_length(). If future architecture revisions support larger vectors later on, my plan is to require an extra "force flag" to be passed to override the clamp. [...] Cheers ---Dave