From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9F7B14A90 for ; Tue, 15 Aug 2023 16:07:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61A16C433C7; Tue, 15 Aug 2023 16:07:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1692115650; bh=5czWxryr8an14tezsiSTtNQm6pcZag0vBREySh9vtr4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VeSOiTj0ACg6L9kyx4p1ShqgxaI1i1fmCDCRjCsqkYjIYBxSm052pyIuLtt/o/44S qSj4yxmS0wAohLDPMtd0mhvjQ+qG9aVbYf6Cz8iBrL9plpExQMN1SIreVHPJ851kWk DL8l4zY8BQ05bcHgAWrII9QvwgW/wSvmOAUpTWXjXNC7hYyAtuB93piEOcfV+vITdG mCn9iDtCtfVqv+xYbplUCtTvu96b1hT+QY+QPRV9MIhFDYlzcH9rogaLDU9jk6dwG2 S/c8wJFs7Zm/vYMuwthE9HcLjYJe64J2j40N66HxZScb8WaZiGSig6wHt3U0lbNDO+ 7BXx3qk7JbnCA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qVwZr-0053ha-RG; Tue, 15 Aug 2023 17:07:28 +0100 Date: Tue, 15 Aug 2023 17:07:27 +0100 Message-ID: <86y1icffwg.wl-maz@kernel.org> From: Marc Zyngier To: Miguel Luis Cc: "kvmarm@lists.linux.dev" , "kvm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Catalin Marinas , Eric Auger , Mark Brown , Mark Rutland , Will Deacon , Alexandru Elisei , Andre Przywara , Chase Conklin , Ganapatrao Kulkarni , Darren Hart , James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: Re: [PATCH v3 15/27] KVM: arm64: nv: Add trap forwarding for HCR_EL2 In-Reply-To: References: <20230808114711.2013842-1-maz@kernel.org> <20230808114711.2013842-16-maz@kernel.org> <85C2D540-7AD7-49BB-9EFB-7F950D08AC15@oracle.com> <87il9gpp2s.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: miguel.luis@oracle.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, eric.auger@redhat.com, broonie@kernel.org, mark.rutland@arm.com, will@kernel.org, alexandru.elisei@arm.com, andre.przywara@arm.com, chase.conklin@arm.com, gankulkarni@os.amperecomputing.com, darren@os.amperecomputing.com, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Tue, 15 Aug 2023 16:35:09 +0100, Miguel Luis wrote: > >>> + [CGT_HCR_NV] =3D { > >>> + .index =3D HCR_EL2, > >>> + .value =3D HCR_NV, > >>> + .mask =3D HCR_NV, > >>> + .behaviour =3D BEHAVE_FORWARD_ANY, > >>> + }, > >>> + [CGT_HCR_NV_nNV2] =3D { > >>> + .index =3D HCR_EL2, > >>> + .value =3D HCR_NV, > >>> + .mask =3D HCR_NV | HCR_NV2, > >>> + .behaviour =3D BEHAVE_FORWARD_ANY, > >>> + }, > >>> + [CGT_HCR_NV1_nNV2] =3D { > >>> + .index =3D HCR_EL2, > >>> + .value =3D HCR_NV | HCR_NV1, > >>> + .mask =3D HCR_NV | HCR_NV1 | HCR_NV2, > >>> + .behaviour =3D BEHAVE_FORWARD_ANY, > >>> + }, > >>=20 > >> The declaration above seems to be a coarse control combination that co= uld be > >> decomposed in the following, more readable, equivalent by adding a > >> combination of two MCBs > >> (eg. CGT_HCR_NV_NV1, CGT_HCR_NV_NV1_nNV2) > >>=20 > >> [CGT_HCR_NV1] =3D { > >> .index =3D HCR_EL2, > >> .value =3D HCR_NV1, > >> .mask =3D HCR_NV1, > >> .behaviour =3D BEHAVE_FORWARD_ANY, > >> }, > >> [CGT_HCR_NV1_nNV2] =3D { > >> .index =3D HCR_EL2, > >> .value =3D HCR_NV1, > >> .mask =3D HCR_NV1 | HCR_NV2, > >> .behaviour =3D BEHAVE_FORWARD_ANY, > >> }, > >>=20 > >> /* FEAT_NV and FEAT_NV2 */ > >> MCB(CGT_HCR_NV_NV1, CGT_HCR_NV, CGT_HCR_NV1)=20 > >>=20 > >> /* FEAT_NV2 and HCR_EL2.NV2 is 0 behaves as FEAT_NV */ > >> MCB(CGT_HCR_NV_NV1_nNV2, CGT_HCR_NV_nNV2, CGT_HCR_NV1_nNV2 ) > >=20 > > This is not equivalent at all, as a MCB is a logical OR, not an AND. > >=20 >=20 > A logical OR as I would expect, which can be used recursively, meaning > IIUC that an MCB can contain other MCB ids, is this correct? We're now forbidding it, but even if we allowed it, it would still be an OR, while you really need an AND. > > Therefore, the equivalent for the declared =E2=80=98CGT_HCR_NV1_nNV2=E2= =80=99 would be >=20 > MCB(CGT_HCR_NV1_nNV2, CGT_HCR_NV_NV1, CGT_HCR_NV_NV1_nNV2) ? You have completely lost me. The only valid values we want to check for at this stage are: {NV}=3D{1} {NV,NV1}=3D{1,1} {NV,NV2}=3D{1,0} {NV,NV1,NV2}=3D{1,1,0} We can check any of these in one go. Why should we build something that implement multiple behaviours in bizarre ways? >=20 > I do not know what I missed. >=20 > >> On the above all the coarse HCR_EL2.{NV,NV1} traps are covered but not= the > >> constrained unpredictable one when HCR_EL2.{NV,NV1} is {0,1} which tra= ps in > >> two of its behaviours and doesn't trap on one. > >=20 > > The current approach makes it plain that HCR_EL2.NV=3D=3D0 doesn't resu= lt > > in any trap forwarding, consistent with the current wording of > > architecture. > >=20 >=20 > Indeed but it could result in trap forwarding as an expected behaviour > in D8.11.4 of DDI0487J.a. Not in our implementation. We ignore NV1 if NV is 0 and behave as "For all purposes other than reading back the value of the HCR_EL2.NV1 bit, the implementation behaves as if HCR_EL2.{NV, NV1} is {0, 0}." The point to understand is that we are implementing *ONE* of the allowed behaviours. We don't have to support all of them. M. --=20 Without deviation from the norm, progress is not possible.