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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 E9E13C2D0A3 for ; Mon, 16 Nov 2020 18:01:06 +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 82E262227F for ; Mon, 16 Nov 2020 18:01:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="df1e4Mu+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 82E262227F Authentication-Results: mail.kernel.org; dmarc=fail (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=ZhO3Amt8InkoLqE6WLKn6gSVFxttUvOK51fKkugdlmc=; b=df1e4Mu+OkdMeweKND+KDl99B 4fC5avZM+1FywOzbAey07AAuNeZK0EFybAQ4QsNlJuSrFfHbanOcr5AlSDGnUxQr7QcxjKRWlhY4G 0lFiH1vBftA7c3TA4blQem5uIXlmnIbrN5ygrVS3mdQnPiuM4V6BJRX2hzBgisn1635yQrcPryVTk nEWMDz3uzaP6a+omJA53uRedMm3D0KOFdrFEfu4VSycbnZGdzlpQRMjTMa5GVKpyalxI18tUW4idq J2Np1tH00ZMaKtpfGoBwZjrOFLUwB/Usu4z8D1hWB2dX9hys1dc8XJPbETJtM4i+GvZ5tIGMHe/iM xUIZcPscQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kein7-00047J-Br; Mon, 16 Nov 2020 17:59:49 +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 1kein3-00046M-Md for linux-arm-kernel@lists.infradead.org; Mon, 16 Nov 2020 17:59:46 +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 D498D30E; Mon, 16 Nov 2020 09:59:44 -0800 (PST) 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 74E613F719; Mon, 16 Nov 2020 09:59:43 -0800 (PST) Date: Mon, 16 Nov 2020 17:59:39 +0000 From: Dave Martin To: Mark Brown Subject: Re: [PATCH v5 1/2] arm64/sve: Don't disable SVE on syscalls return Message-ID: <20201116175938.GA6882@arm.com> References: <20201106193553.22946-1-broonie@kernel.org> <20201106193553.22946-2-broonie@kernel.org> <20201113184855.GF3212@gaia> <20201113201328.GG4828@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201113201328.GG4828@sirena.org.uk> 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-20201116_125945_941865_528237E8 X-CRM114-Status: GOOD ( 22.40 ) 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 , 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 Fri, Nov 13, 2020 at 08:13:28PM +0000, Mark Brown wrote: > On Fri, Nov 13, 2020 at 06:48:56PM +0000, Catalin Marinas wrote: > > On Fri, Nov 06, 2020 at 07:35:52PM +0000, Mark Brown wrote: > > > From: Julien Grall > > > > We could instead handle flushing the SVE state in do_el0_svc() however > > > doing this reduces the potential for further optimisations such as > > > initializing the SVE registers directly from the FPSIMD state when > > > taking a SVE access trap and has some potential edge cases if we > > > schedule before we return to userspace after do_el0_svc(). > > > Ah, you covered the do_el0_svc() topic here already. Is this potential > > optimisation prevented because TIF_SVE has two meanings: SVE access > > enabled and sve_state valid (trying to page this code in)? For example, > > task_fpsimd_load() uses TIF_SVE to check whether to load from sve_state > > or from fpsimd. fpsimd_bind_task_to_cpu() uses TIF_SVE to enable the > > user access. > > Yes, there's some overloading with the storage for the SVE register file > and the new flag is effectively about the storage. Right. First and foremost, TIF_SVE means "userspace is allowed to access the SVE regs". To guarantee that we have somewhere to save the regs at short notice, I also made sure that the SVE regs backing storage (sve_state) is allocated before setting this flag. This allows critical path code to assume the storage is valid whenever a need to save the SVE regs arises. So, TIF_FOREIGN_FPSTATE and TIF_SVE are independent, and mean: * TIF_SVE true: sve_state allocated (and large enough); userspace is allowed to access the SVE regs directly. * TIF_SVE false: sve_state may not be allocated; userspace is not allowed to access the SVE regs directly; their logical contents are all 0 (except for vl, which is persistent independent of all these flags). * TIF_FOREIGN_FPSTATE false (and task running): the hardware regs are up to date for current; task may be in user or kernelspace. * TIF_FOREIGN_FPSTATE true (and task running): the hardware regs may not be up to date for current; task definitely in kernelspace. * task scheduled out: similar to TIF_FOREIGN_FPSTATE true: the hardware regs may not be up to date for task; task in kernelspace FWIW. For the most part, we can treat this the same as "TIF_FOREIGN_FPSTATE true". So far as I can see, TIF_SVE_NEEDS_FLUSH is a special state in which SVE is half-enabled and the SVE regs half-loaded, so it's not an orthogonal flag, but a distinct state that sits between the others. In this state the regs are neither fully saved nor fully loaded, and we haven't committed to either enabling or disabling SVE for userspace. It's an intermediate state which we can choose our path out of based on policy or performance concerns. The new state's closest relative is probably TIF_SVE && !TIF_FOREIGN_FPSTATE. Akin to that state, sve_state is valid, and ZCR_EL1.LEN is loaded. But we do have a bit of work to do in order to transition to most of the other states. I will try to come up with a state diagram, but not today... I'll look at the code and these other comments tomorrow. [...] Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel