From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A754C433E3 for ; Wed, 15 Jul 2020 16:54:21 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 669EB20672 for ; Wed, 15 Jul 2020 16:54:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cgwWVglw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 669EB20672 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=TutY1TvhvHrqXE5g60bC64TMMBfnKOBHw3qK4L/+g3M=; b=cgwWVglwbpZMlIEQf4UGEervj 3Jau6EiYiDzl1qDAZ6GS5EECz3Qb0B+tL2v6se3LcL1RtoWO9yhv83O4u32892rl3wq0DLqDq59FM aYLCi+9NqhQXzoglW8egTkQ3ct9ICKxwNqc2YoCW3zL/fGi7TMjDCdI7iBCbuzj2P9RFUMzdvgOC0 BdTWwxXlRiJq/Y20oPKxNloP/V5dn48zA1nUG3cz9Ge3bWmGjssCr8AT9PfYeMVjrrxl8ROWR35cj AWMvN3BhHQRUxseCV1cSfSYziEa2ZInaPxU5m/W88yk8djluX1lttrp3/LY/wiudY0vkaD/nWCdjv dfwMfuqIg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvkeW-0006QR-7h; Wed, 15 Jul 2020 16:53:04 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvkeS-0006LO-Pp for linux-arm-kernel@lists.infradead.org; Wed, 15 Jul 2020 16:53:02 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6519E31B; Wed, 15 Jul 2020 09:52:59 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AD0273F718; Wed, 15 Jul 2020 09:52:56 -0700 (PDT) Date: Wed, 15 Jul 2020 17:52:54 +0100 From: Dave Martin To: Mark Brown Subject: Re: [PATCH v3 8/8] arm64/sve: Rework SVE trap access to use TIF_SVE_NEEDS_FLUSH Message-ID: <20200715165254.GG30452@arm.com> References: <20200629133556.39825-1-broonie@kernel.org> <20200629133556.39825-9-broonie@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200629133556.39825-9-broonie@kernel.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200715_125301_150332_4DF25A05 X-CRM114-Status: GOOD ( 33.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Catalin Marinas , zhang.lei@jp.fujitsu.com, Julien Grall , Will Deacon , linux-arm-kernel@lists.infradead.org, Daniel Kiss Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jun 29, 2020 at 02:35:56PM +0100, Mark Brown wrote: > From: Julien Grall > > SVE state will be flushed on the first SVE access trap. At the moment, > the SVE state will be generated from the FPSIMD state in software and > then loaded in memory. > > It is possible to use the newly introduce flag TIF_SVE_NEEDS_FLUSH to > avoid a lot of memory access. > > If the FPSIMD state is in memory, the SVE state will be loaded on return > to userspace from the FPSIMD state. > > If the FPSIMD state is loaded, then we need to set the vector-length > before relying on return to userspace to flush the SVE registers. This > is because the vector length is only set when loading from memory. We > also need to rebind the task to the CPU so the newly allocated SVE state > is used when the task is saved. Reasonable overall, I think. A few minor queries below. > Signed-off-by: Julien Grall > Signed-off-by: Mark Brown > --- > arch/arm64/include/asm/fpsimd.h | 2 ++ > arch/arm64/kernel/entry-fpsimd.S | 5 +++++ > arch/arm64/kernel/fpsimd.c | 35 ++++++++++++++++++++++---------- > 3 files changed, 31 insertions(+), 11 deletions(-) > > diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h > index bec5f14b622a..e60aa4ebb351 100644 > --- a/arch/arm64/include/asm/fpsimd.h > +++ b/arch/arm64/include/asm/fpsimd.h > @@ -74,6 +74,8 @@ extern void sve_load_from_fpsimd_state(struct user_fpsimd_state const *state, > unsigned long vq_minus_1); > extern unsigned int sve_get_vl(void); > > +extern void sve_set_vq(unsigned long vq_minus_1); > + > struct arm64_cpu_capabilities; > extern void sve_kernel_enable(const struct arm64_cpu_capabilities *__unused); > > diff --git a/arch/arm64/kernel/entry-fpsimd.S b/arch/arm64/kernel/entry-fpsimd.S > index 5b1a9adfb00b..476c8837a7e5 100644 > --- a/arch/arm64/kernel/entry-fpsimd.S > +++ b/arch/arm64/kernel/entry-fpsimd.S > @@ -48,6 +48,11 @@ SYM_FUNC_START(sve_get_vl) > ret > SYM_FUNC_END(sve_get_vl) > Might be worth a comment here to remind us that x0 is the vq minus 1. > +SYM_FUNC_START(sve_set_vq) > + sve_load_vq x0, x1, x2 > + ret > +SYM_FUNC_END(sve_set_vq) > + > /* > * Load SVE state from FPSIMD state. > * > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > index ccbc38b71069..dfe2e19ce591 100644 > --- a/arch/arm64/kernel/fpsimd.c > +++ b/arch/arm64/kernel/fpsimd.c > @@ -944,10 +944,10 @@ void fpsimd_release_task(struct task_struct *dead_task) > /* > * Trapped SVE access > * > - * Storage is allocated for the full SVE state, the current FPSIMD > - * register contents are migrated across, and TIF_SVE is set so that > - * the SVE access trap will be disabled the next time this task > - * reaches ret_to_user. > + * Storage is allocated for the full SVE state so that the code > + * running subsequently has somewhere to save the SVE registers to. We > + * then rely on ret_to_user to actually convert the FPSIMD registers > + * to SVE state by flushing as required. > * > * TIF_SVE should be clear on entry: otherwise, fpsimd_restore_current_state() > * would have disabled the SVE access trap for userspace during > @@ -965,14 +965,24 @@ void do_sve_acc(unsigned int esr, struct pt_regs *regs) > > get_cpu_fpsimd_context(); > > - fpsimd_save(); > - > - /* Force ret_to_user to reload the registers: */ > - fpsimd_flush_task_state(current); > + set_thread_flag(TIF_SVE_NEEDS_FLUSH); > + /* > + * We should not be here with SVE enabled. TIF_SVE will be set > + * before returning to userspace by fpsimd_restore_current_state(). > + */ > + WARN_ON(test_thread_flag(TIF_SVE)); > > - fpsimd_to_sve(current); > - if (test_and_set_thread_flag(TIF_SVE)) > - WARN_ON(1); /* SVE access shouldn't have trapped */ > + /* > + * When the FPSIMD state is loaded: > + * - The return path (see fpsimd_restore_current_state) requires > + * the vector length t be loaded beforehand. Nit: to > + * - We need to rebind the task to the CPU so the newly allocated > + * SVE state is used when the task is saved. > + */ > + if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { > + sve_set_vq(sve_vq_from_vl(current->thread.sve_vl) - 1); > + fpsimd_bind_task_to_cpu(); Hmm, does this actually to the sve_user_enable(), duplicating the sve_user_enable() in fpsimd_restore_current_state()? > + } > > put_cpu_fpsimd_context(); > } > @@ -1189,6 +1199,9 @@ void fpsimd_restore_current_state(void) > /* > * The userspace had SVE enabled on entry to the kernel > * and requires the state to be flushed. > + * > + * We rely on the Vector-Length to be set correctly before-hand Trivial nit: I think we normally just write "vector length". Could be worth saying where it gets done (i.e., do_sve_acc()). > + * when converting a loaded FPSIMD state to SVE state. > */ > sve_flush_live(); > sve_user_enable(); Possibly redundant? See do_sve_acc(). Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel