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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1AC66C3DA42 for ; Wed, 10 Jul 2024 17:16:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A41286B0099; Wed, 10 Jul 2024 13:16:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F2046B009C; Wed, 10 Jul 2024 13:16:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B8BC6B009D; Wed, 10 Jul 2024 13:16:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 68F566B0099 for ; Wed, 10 Jul 2024 13:16:53 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 18D7E1A00E8 for ; Wed, 10 Jul 2024 17:16:53 +0000 (UTC) X-FDA: 82324497906.23.84AACDA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf24.hostedemail.com (Postfix) with ESMTP id 3E86618001F for ; Wed, 10 Jul 2024 17:16:51 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=gj3wTGeG; spf=pass (imf24.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720631779; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aMZjfCYHtwZ0AjyF19LAqJEndOvi0wT+wymbjRUuOLE=; b=2sT4bWKeHzzbpjpipV1Ie8pljQCv64YltcprGPGVDYYD9xOS8KQzc2e5IDz+aja/kMozgt P1uJoOzhEU0l4kaovXPVWW7WXiTzMZln2OWWN/oqIRGoCAeiagsFCEo6J1DeW2R7i5QIPn QlP+QLp5mCbIPnUl5cnMOAZieSuTQnE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720631779; a=rsa-sha256; cv=none; b=zuY7aHf0x0mdhyAd4wtfDW1ZHnLLItWqlNmKu7HnPLAYbgn6ES+TaBD9JB6+ZTQzliFhWM cDypEHWjEXzvZfbdidObBV2f4DY22LQGj9E/w/MIwDb/yqn2E4RkVow5Oe0m7uQhdzCr1e rlA9JfpCEGUJKqxNWX3YU7RilQJ5xdM= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=gj3wTGeG; spf=pass (imf24.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 49F8E6190C; Wed, 10 Jul 2024 17:16:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67AEFC32781; Wed, 10 Jul 2024 17:16:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720631810; bh=gbQbaUuiVBZ3rY0fazMfEsDsmp1EJvBByE9rwhcqv1M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gj3wTGeGvkQA66hJtscYz2CdurW/XaWmXT1LUad7xHcQlV6bJlMPYB6BYkarkGJzM qb1fJH/GWYe++EsAN1YPqxKxmTx70mi2pArTryxpc+tBbCuVT8RugoF5J51N45APGN x+ezB+0+cMxlPHdLjUWzayfTJu8mxxY70OY7vRayQ0pqy+eEScxUw5lPNBlw9PM4pl gHRJ2FF3NJhmef1/MM9944Z03bUSEMfjwNa8lSQVOBXi6SLTpzX79Nj4r2tZ5j+E5e PNrecmTOcerZ2rr+jDaPAfXGPZUcWnJiE7MQ+AaJcdd8y8iMm1ukZWkjVH5FmwuAtd 4eGDODAKNmXiA== Date: Wed, 10 Jul 2024 18:16:46 +0100 From: Mark Brown To: Marc Zyngier Cc: Catalin Marinas , Will Deacon , Jonathan Corbet , Andrew Morton , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Thiago Jung Bauermann , Ross Burton , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v9 13/39] KVM: arm64: Manage GCS registers for guests Message-ID: References: <20240625-arm64-gcs-v9-0-0f634469b8f0@kernel.org> <20240625-arm64-gcs-v9-13-0f634469b8f0@kernel.org> <86v81d2s5t.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tsBiN+tG2JsDrdFj" Content-Disposition: inline In-Reply-To: <86v81d2s5t.wl-maz@kernel.org> X-Cookie: Your love life will be... interesting. X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 3E86618001F X-Stat-Signature: nonceujt87sk9yu8b44rbmwo7prfnexo X-HE-Tag: 1720631811-143036 X-HE-Meta: U2FsdGVkX181SJLbEKDwTRmqjmG8vsBBY3JcRfC/VkAyZeylmf+Gr+02HlKFtAfx/+H0N5voCs9F/pz/rmJ2UC6gallkKu5K3Uk5Xzt08yPZ1jL7WJtYqJjT6HONhKJWHxh0q8ZIVVHDlsdvzpY/VW9TvwHk48UZKLDtI/EJxXGk9/jcaTvvtzZ319ZYyQetT2i9NEXOd8Rl/oDc4ILJwXLxtIumhttOlqnm/lZO9VE8HLyL16eOEycxpvKr2mJF3E3SK9vWpsSerz4HazlFuajtzgPxqNAEszh0DuHT8Dz+5k+3HX6BcpyOe59zkPXE3QK+xdzewDJMjQjn2TSs77QZ7Pi/jjf+xb+2TvgAXTO2vft+YASkiTO53FuhXOQs6C6GNCdOGO5zleio/kvSKZ4j81RrHjUYz5NEynkJ1fQQBqaouVsHeredjF9GBaXbwXMYNr/xqFuOBM8UeAvsOAHkNuTgXWF2VRCnfhG89blmTUF692jYHtN5VdkHJ0YegdMp+hgMAdVNHEYLwDYpqTxNYd9TWkYvHMn3yjD1BC6ZBs1NImI4HowBYFysVnmnxltbaPRbgRq2KIJ37HRxzfDoq+hPGRx5IYMP6ZXKohTZEgoQ70YqaJsV5Udbc64ZBuq04FrbZaLTp6/PsdBgoveokne8hYhnQyJG6Q/+OJuJ8wfTLIPm2dNrQ8go/NO5mcAvFSQlxWe0KUxsMxqwqrBjsRqO9AQokb1zbwdyY8TBBJq+IQ0O9V5J5If9sOurmv8HQla1kBhpdANHXwbBeMFBrbKIVKdeIxDUHWvTLYAsdreqxgPUdaa49l45emiLKyuNAe88caYAUEGwSKK23vclPsweq2iuCP0awIpgbLXYryDzMbpOn0IS4Hnp5S1og+nQ+DJ2cCiVQkIPensUNNBkEUbkQfhI1ZlMikdUjIah3oWUNd8t6ohxkidUK0YMWxOiBP7sCxGC40E6yoo z6n5eZH2 Bfi2ZJO6vJHAS3Q8YeWovfHccCwSLfAJSUmyhmAsawzfhdM+e2eElGuECGLC3LbZHY+lBujN8bwlYL3TipUjbp+zKhygLLWPqrFebCMmLS9emZ7wA7vIZZdBoxFAvGR6/YeTQ/d00hZr6qs03Z/KHWQzgxvS/BItyDnE8kh/qmWQvPQ9kdZXIA0i12537boY4pOuS4hk8PSuCsN2LgJXxFI8iYJWTnLqoBGL3cvcx+2jf8iLYphfM2icpO+r+q8MyaBu/HwvxKIMTLkyeR6uSvpbFNpj3rdCDRcjtewsRpsbMkLWVvXMhH27XE6xfWVfj44TDG7SnI1ci1/b3Xc7bpvFNCD/0DIazrM/kPctG/yteLMySxL5vk6sAKwBbqwvF/PwA+k+u2rQ+qpct/5OB8jg7psX6czN/6Cxp X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --tsBiN+tG2JsDrdFj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 10, 2024 at 04:17:02PM +0100, Marc Zyngier wrote: > Mark Brown wrote: > > + if (ctxt_has_gcs(ctxt)) { > Since this is conditioned on S1PIE, it should be only be evaluated > when PIE is enabled in the guest. So make ctxt_has_gcs() embed a check of ctxt_has_s1pie()? > > + ctxt_sys_reg(ctxt, GCSPR_EL1) = read_sysreg_el1(SYS_GCSPR); > > + ctxt_sys_reg(ctxt, GCSCR_EL1) = read_sysreg_el1(SYS_GCSCR); > > + ctxt_sys_reg(ctxt, GCSCRE0_EL1) = read_sysreg_s(SYS_GCSCRE0_EL1); > Why is this part of the EL1 context? It clearly only matters to EL0 > execution, so it could be switched in load/put on nVHE as well. And > actually, given that the whole thing is strictly for userspace, why do > we switch *anything* eagerly at all? GCS can also be used independently at EL1 (and EL2 for that matter), it's not purely for userspace even though this series only implements use in userspace. GCSPR_EL1 and GCSCR_EL1 control the use of GCS at EL1, not EL0, and the guest might be using GCS at EL1 even if the host doesn't. GCSCRE0_EL1 is for EL0 though, it ended up here mainly because it's an _EL1 register and we are already context switching PIRE0_EL1 in the EL1 functions so it seemed consistent to follow the same approach for GCS. The _el1 and _user save/restore functions are called from the same place for both VHE and nVHE so the practical impact of the placement should be minimal AFAICT. Unlike PIRE0_EL1 GCSCRE0_EL1 only has an impact for code runnning at EL0 so I can move it to the _user functions. TBH I'm not following your comments about switching eagerly too here at all, where would you expect to see the switching done? You've said something along these lines before which prompted me to send a patch to only save the S1PIE registers if they'd been written to which you were quite reasonably not happy with given the extra traps it would cause: https://lore.kernel.org/r/20240301-kvm-arm64-defer-regs-v1-1-401e3de92e97@kernel.org but I'm at a loss as to how to make things less eager otherwise. > > @@ -2306,7 +2323,8 @@ static const struct sys_reg_desc sys_reg_descs[] = { > > ID_AA64PFR0_EL1_GIC | > > ID_AA64PFR0_EL1_AdvSIMD | > > ID_AA64PFR0_EL1_FP), }, > > - ID_SANITISED(ID_AA64PFR1_EL1), > > + ID_WRITABLE(ID_AA64PFR1_EL1, ~(ID_AA64PFR1_EL1_RES0 | > > + ID_AA64PFR1_EL1_BT)), > I don't know what you're trying to do here, but that's not right. If > you want to make this register writable, here's the shopping list: > https://lore.kernel.org/all/87ikxsi0v9.wl-maz@kernel.org/ Yes, trying to make things writable. I do see we need to exclude more bits there and I'm not clear why I excluded BTI, looks like I forgot to add a TODO comment at some point and finish that off. Sorry about that. In the linked mail you say you want to see all fields explicitly handled, could you be more direct about what such explicit handling would look like? I see a number of examples in the existing code like: ID_WRITABLE(ID_AA64ZFR0_EL1, ~ID_AA64ZFR0_EL1_RES0), ID_WRITABLE(ID_AA64ISAR0_EL1, ~ID_AA64ISAR0_EL1_RES0), ID_WRITABLE(ID_AA64ISAR1_EL1, ~(ID_AA64ISAR1_EL1_GPI | ID_AA64ISAR1_EL1_GPA | ID_AA64ISAR1_EL1_API | ID_AA64ISAR1_EL1_APA)), which look to my eye very similar to the above, they do not visibliy explictly enumerate every field in the registers and given that there's a single mask specified it's not clear how that would look. If ID_WRITABLE() took separate read/write masks and combined them it'd be more obvious but it's just not written that way. --tsBiN+tG2JsDrdFj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmaOwf0ACgkQJNaLcl1U h9BiTwgAhG9qd8c+aLOWRDYY+jgC3wxTF25VtO52AztM2Y4fyGfPMHg+GgALH/zW kZPNqJcbu5fDOfkUg3obwE/dUqdlZDlbmmJBnaP1E9p3sXWuQ9sedlO17lyf3w8h mzzFxLDCS0j01M5YNj4ql9LmC4sTOWyuzvzKDzDnLfM93Jdj6nhT4S0si+iQdBB8 PFhjdtH6qVUmQNG3ik40q/IPe+nA4u0mgs7XpKj8PuPtVDxe4SNhB8cZ8R+pEJBZ f3EHvbndiotEBkFARu84AC/F3XfNhGNYlaZg/fwr2yfpfpFV/1Cz0LABhH9WojA0 z7VzLkWe/+pqYeMUNAJY6H+YDudaLA== =InCr -----END PGP SIGNATURE----- --tsBiN+tG2JsDrdFj--