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 B8BF7C352A1 for ; Wed, 7 Dec 2022 14:17:57 +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-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-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Nv98Gs5v0+pYPaWsnefogDtTfWpaTleL88yjbzUeK+0=; b=Xpp2slXTIG/k4woFvkc9ZXb/HS Sw+XkBKNCC/+MMLG1RVNOhRnCaYZg/C6zhClKhEUMgb/S2BBkQkJVUCVXT+23AkUg2Gjz6hIJ+CjL 63eN0HXSbXlQHADMa3UpqNOvmsbRhiNYU+DLesyCH7tXS9Kr5JCQN2ux/i6gRYCyc6kOGOVVkpDrr 0MmTuoYmRDnj5Tpij10ZOyQ+PryHlIfy5EVkPxYma3hKGj39d9XekTDbo2tdI/KwoK43odLPcZto4 +xCx4k38F67Ltq6IeZGGHhTn1SuZx5RgiyOVp/0gr39VsN/4jWs0/1lcTTKt31XN0ER8SCfQ+gTHg U410jn4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p2vE7-004fRR-9z; Wed, 07 Dec 2022 14:16:47 +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 1p2vE4-004fQp-Rq for linux-arm-kernel@lists.infradead.org; Wed, 07 Dec 2022 14:16:46 +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 BF90361798; Wed, 7 Dec 2022 14:16:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86871C433C1; Wed, 7 Dec 2022 14:16:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670422603; bh=r3u8Dix8avniHqNjnYoG3w/Uhbpr86KS5aLsZSxY9h4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PfLETTKsFfL9c3rBgI7mKeD+wjxVnNTwOjYgUIX9CV7ItKFN2QB/maSG16lWXJueh SBmkoc+C4jZArNpcDOvaNLjrxV5acIjXboi+Xy764T1Iie+AlkFcJz49uPBSbff1lf CHfqeSSt9U6OZ7NykFsw9hWr1XYSWttUw+kUn0LpJOebbE6OENJZ6o6eFf5m46Zf4U bWkrafdEJr+rXy4fK1RB1ngvs6XNSNMmnVPMbCDEuAl3zvA578DTfGPyuli716TlS7 VjvsgmXY6yabmrK9WaQlZPITOi46yVGKGlhNORBqEjCh+/ib84MLij/KDgzm+1lz0O dS4bcXMpp4qKg== Date: Wed, 7 Dec 2022 14:16:36 +0000 From: Mark Brown To: Zenghui Yu Cc: Catalin Marinas , Will Deacon , Marc Zyngier , Shuah Khan , Shuah Khan , Basant Kumar Dwivedi , Luis Machado , Szabolcs Nagy , linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org, Alan Hayward , kvmarm@lists.cs.columbia.edu, Salil Akerkar , Luca Salabrino Subject: Re: [PATCH v14 16/39] arm64/sme: Implement traps and syscall handling for SME Message-ID: References: <20220419112247.711548-1-broonie@kernel.org> <20220419112247.711548-17-broonie@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Cookie: What!? Me worry? X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221207_061644_995163_37E00D25 X-CRM114-Status: GOOD ( 23.65 ) 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: multipart/mixed; boundary="===============7775318825347070595==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============7775318825347070595== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xw/WPICFk6OpWXHF" Content-Disposition: inline --xw/WPICFk6OpWXHF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Dec 07, 2022 at 10:00:17PM +0800, Zenghui Yu wrote: > On 2022/4/19 19:22, Mark Brown wrote: > > + /* > > + * 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 > It looks a bit confusing to me that in the current implementation, if > ZA is *not* active, we don't actually go to disable SME for the task > (which IMHO can be disabled as user-space is not actively using it now). Unlike SVE there's no overhead from leaving SME enabled, the enable bits for SM and ZA tell us if there is extra register state to be saved so we don't have to worry about the costs there like we do with SVE. The only reason for not just unconditionally enabling SME is the potentially large backing storage required for the registers, if a task isn't using SME there's no need to impose that overhead. If we disable SME for userspace after the storage has been allocated then we just require an additional trip through EL1 to reenable it for any future usage which would hurt performance but not really gain us anything otherwise. We don't want to discurage applications from disabling ZA when not in use given that there's likely to be physical overheads from keeping it enabled. > > + if (svcr & SYS_SVCR_EL0_SM_MASK) > > + sme_smstop_sm(); > As per the SME syscall ABI > | On syscall PSTATE.SM will be cleared and the SVE registers will be > | handled as per the standard SVE ABI. > and the SVE syscall ABI > | On syscall, V0..V31 are preserved (as without SVE). Thus, bits > | [127:0] of Z0..Z31 are preserved. All other bits of Z0..Z31, and all > | of P0..P15 and FFR become zero on return from a syscall. > Can we infer from the documentation that V0-V31 should be preserved on > return from a syscall? But with sme_smstop_sm(), all implemented bits of > Z0-Z31 are set to zero by hardware. Is this intentional? > Please fix me up if I've mis-read things here. No, the intention is to say that we exit streaming mode and then handle things as per the non-streaming ABI. Exiting streaming mode has the effect of clearing the values as you say. --xw/WPICFk6OpWXHF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmOQoEQACgkQJNaLcl1U h9DT2Qf/ZwEng2pEy0USKIPgcxnkZZTR1rImCaFy06I5mkGLN2DsF874tUEjlLVH m3jTS9+Ekzmj+bHTrJ/E93HzlWGmWaAx+zAQy/Hx67A/wOraXL00RRSYjZ2QrHTm 0mZTDm2Cv6Y/Aqep2HbZAAyoyckjJXslXQZdpSM2ZHm3ZEWxUigtc+xHkQDw58qQ /ZASpPtcm19SinaFJXXP4wPv5CU2hm1kXGvwdg16weggR5ro/3za6RFB63Up1VQ7 KQkppEUTmEaM4grb0JAYHFcr+gFcKIbXCaLqtkrClziQrHlAPJ/Rr9CXSTCuC8S/ K1UFr0G52c72xm1AZd1w9MrWDFOhuA== =abex -----END PGP SIGNATURE----- --xw/WPICFk6OpWXHF-- --===============7775318825347070595== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============7775318825347070595==--