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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 42346C433F5 for ; Tue, 22 Feb 2022 17:56:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=nekt5ZEZsuLzvO3/5VDW5Ip8SLj0WS1hZJ5jRCyRO4s=; b=OJWkeJaI2PKiEF P8GlEMHBnt1Sk+5hTaKiQhX9vO2z38DqrG6QTWyWIEqByLVMvuIOGAd3WcfWwFzGpKYZ9FwvZQhrU nBfhXnZCJFT9rcGGIVOVYB8fR8/VotvZ7g3Tp/037Ugdn/a9Ev0zDbIgCJrXVPFqFGwLhWbvBBJt+ GsdS/k+PW16XpeZ5hplm/Jyeu+hs0bmutmhKlfHub2iPF991826YXQY7IzyyCEZkGhjF/hwu6Bocl ZIzI6tGoicNkGancspYZ/vgX10+rMlSCZLR54NBATJreswjQGOhQfY+3V++f4RIxrMk5R2bSvKvOu ntkTZqNfJcBY/+S4/OVg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nMZNJ-00B56i-MG; Tue, 22 Feb 2022 17:54:57 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nMZNF-00B559-4L for linux-arm-kernel@lists.infradead.org; Tue, 22 Feb 2022 17:54:54 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0454A6142C; Tue, 22 Feb 2022 17:54:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8629FC340E8; Tue, 22 Feb 2022 17:54:48 +0000 (UTC) Date: Tue, 22 Feb 2022 17:54:45 +0000 From: Catalin Marinas To: Mark Brown Cc: Will Deacon , Marc Zyngier , Shuah Khan , Shuah Khan , Alan Hayward , Luis Machado , Salil Akerkar , Basant Kumar Dwivedi , Szabolcs Nagy , James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org, kvmarm@lists.cs.columbia.edu Subject: Re: [PATCH v11 18/40] arm64/sme: Implement traps and syscall handling for SME Message-ID: References: <20220207152109.197566-1-broonie@kernel.org> <20220207152109.197566-19-broonie@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220207152109.197566-19-broonie@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220222_095453_275872_3134AAC4 X-CRM114-Status: GOOD ( 30.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, Feb 07, 2022 at 03:20:47PM +0000, Mark Brown wrote: > By default all SME operations in userspace will trap. When this happens > we allocate storage space for the SME register state, set up the SVE > registers and disable traps. We do not need to initialize ZA since the > architecture guarantees that it will be zeroed when enabled and when we > trap ZA is disabled. > > On syscall we exit streaming mode if we were previously in it and ensure > that all but the lower 128 bits of the registers are zeroed while > preserving the state of ZA. This follows the aarch64 PCS for SME, ZA > state is preserved over a function call and streaming mode is exited. I'm not sure this is entirely correct about the PCS. The caller must disable SM if the function it calls is not compatible. But it's fine for the kernel to impose this at the ABI level. > @@ -409,6 +415,21 @@ static void task_fpsimd_load(void) > restore_ffr); > else > fpsimd_load_state(¤t->thread.uw.fpsimd_state); > + > + /* > + * If we didn't set up any SVE registers but we do have SME > + * enabled for userspace then ensure the SVE registers are > + * flushed since userspace can switch to streaming mode and > + * view the register state without trapping. > + */ > + if (system_supports_sme() && test_thread_flag(TIF_SME) && > + !restore_sve_regs) { > + int sve_vq_minus_one; > + > + sve_vq_minus_one = sve_vq_from_vl(task_get_sve_vl(current)) - 1; > + sve_set_vq(sve_vq_minus_one); > + sve_flush_live(true, sve_vq_minus_one); > + } Shouldn't the SVE state be flushed by the hardware when switching to streaming mode? > +/* > + * As per the ABI exit SME streaming mode and clear the SVE state not > + * shared with FPSIMD on syscall entry. > + */ > +static inline void fp_user_discard(void) > { > + /* > + * If SME is active then exit streaming mode. If ZA is active > + * then flush the SVE registers but leave userspace access to > + * both SVE and SME enabled, otherwise disable SME for the > + * task and fall through to disabling SVE too. This means > + * that after a syscall we never have any SME register state > + * to track, if this changes the KVM code will need updating. > + */ By "we never have any SME register state to track" I understand that we drop the ZA state as well which AFAICT is not the case. > + if (system_supports_sme() && test_thread_flag(TIF_SME)) { > + u64 svcr = read_sysreg_s(SYS_SVCR_EL0); > + > + if (svcr & SYS_SVCR_EL0_SM_MASK) > + sme_smstop_sm(); > + > + if (!(svcr & SYS_SVCR_EL0_ZA_MASK)) { > + clear_thread_flag(TIF_SME); > + sme_user_disable(); > + } > + } -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel