Received-SPF: pass (google.com: domain of linux-kernel+bounces-55076-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Content-Type: multipart/signed;
 boundary=a57af45cc5955d68bdbf93fbe21e37380f2864359968660b19cc3d7e95c6;
 micalg=pgp-sha256; protocol="application/pgp-signature"
Precedence: bulk
Mime-Version: 1.0
Date: Tue, 06 Feb 2024 15:07:10 +0100
Message-Id: <CYY1YXL0FWK2.1L5CRNMKUF22J@gmail.com>
Cc: "Sumit Gupta" <sumitg@nvidia.com>, <treding@nvidia.com>,
 <krzysztof.kozlowski@linaro.org>, <mark.rutland@arm.com>,
 <linux-kernel@vger.kernel.org>, <linux-tegra@vger.kernel.org>,
 <amhetre@nvidia.com>, <bbasu@nvidia.com>
Subject: Re: [Patch] memory: tegra: Skip SID override from Guest VM
From: "Thierry Reding" <thierry.reding@gmail.com>
To: "Marc Zyngier" <maz@kernel.org>, "Jon Hunter" <jonathanh@nvidia.com>
References: <20240206114852.8472-1-sumitg@nvidia.com>
 <86wmrh6b2n.wl-maz@kernel.org>
 <252d6094-b2d6-496d-b28f-93507a193ede@nvidia.com>
 <86v87169g2.wl-maz@kernel.org>
In-Reply-To: <86v87169g2.wl-maz@kernel.org>

--a57af45cc5955d68bdbf93fbe21e37380f2864359968660b19cc3d7e95c6
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

On Tue Feb 6, 2024 at 1:53 PM CET, Marc Zyngier wrote:
> On Tue, 06 Feb 2024 12:28:27 +0000, Jon Hunter <jonathanh@nvidia.com> wro=
te:
> > On 06/02/2024 12:17, Marc Zyngier wrote:
[...]
> > > - My own tegra186 HW doesn't have VHE, since it is ARMv8.0, and this
> > >    helper will always return 'false'. How could this result in
> > >    something that still works? Can I get a free CPU upgrade?
> >=20
> > I thought this API just checks to see if we are in EL2?
>
> It does. And that's the problem. On ARMv8.0, we run the Linux kernel
> at EL1. Tegra186 is ARMv8.0 (Denver + A57). So as written, this change
> breaks the very platform it intends to support.

To clarify, the code that accesses these registers is shared across
Tegra186 and later chips. Tegra194 and later do support ARMv8.1 VHE.

Granted, if it always returns false on Tegra186 that's not what we
want.

> > > - If you assign this device to a VM and that the hypervisor doesn't
> > >    correctly virtualise it, then it is a different device and you
> > >    should simply advertise it something else. Or even better, fix you=
r
> > >    hypervisor.
> >=20
> > Sumit can add some more details on why we don't completely disable the
> > device for guest OSs.
>
> It's not about disabling it. It is about correctly supporting it
> (providing full emulation for it), or advertising it as something
> different so that SW can handle it differently.

It's really not a different device. It's exactly the same device except
that accessing some registers isn't permitted. We also can't easily
remove parts of the register region from device tree because these are
intermixed with other registers that we do want access to.

> Poking into the internals of how the kernel is booted for a driver
> that isn't tied to the core architecture (because it would need to
> access system registers, for example) is not an acceptable outcome.

So what would be the better option? Use a different compatible string to
make the driver handle the device differently? Or adding a custom
property to the device tree node to mark this as running in a
virtualized environment?

Perhaps we can reuse the top-level hypervisor node? That seems to only
ever have been used for Xen on 32-bit ARM, so not sure if that'd still
be appropriate.

Thierry

--a57af45cc5955d68bdbf93fbe21e37380f2864359968660b19cc3d7e95c6
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmXCPQ4ACgkQ3SOs138+
s6FwlQ//VXIIRE1nFoDgCaZ79DgjEg3oOeQn6S/vAx4tfVMtsRrkpmxy4y56+/ft
lOjQ7mmXqYJiMVIoNVdxDEcZfwVsE740IDjsuJpMmI10BmZ4siqVc6Mj3ZmVwwKo
g46SrmLzXDMmhhT+YSdc0IoHhrDSU7XJTxig0cKaGRv44YQrsrKAjyRxtUVblHTg
wO7Ybxq1c+z2AKlhTEBUNgcaxUcQ9jBze6Gki3kuHOVpkxtRrZdxmHz41CtBkhim
cVVCufxKtrcBkGY0iYlF7I8eZhL1xaXQtdoIzPZ9A6Bla2LVx/fICkwHqH2aCzjg
9RrzH5tuHvv46vFC70BK2VK0fwdlxvvUMZJPZUqtFMTagz/JdyG3FredDhaPPp3Z
LN5xAoDiqOLucBlygGSOhBd4002KOowMtDN6fYDXVFN+nUJc0g5xUJPBUXoUwYDb
kr/Gh/RtaKdE4/4hcdHITNrPCUgv4TKkBMqMOynkTSEzwF24nHA6gHuLNd6E9ntB
2TpldvhxZaUfEeKGxtdGV0AVTIrxgZvBFUxINhbrJWW8W8pijh2iM/D4q9vBdT4R
mkE8ResmkedMQo8pYx4boSI9whZdt0bC8s/KSoTWuvEoM7BSsVZ1ibnLKOEQC6fu
PdYvbal6LrrRUlNAUlum8gCz7nXmPbKctnRHt2x6JKD0Tz/Cj/I=
=Ow9u
-----END PGP SIGNATURE-----

--a57af45cc5955d68bdbf93fbe21e37380f2864359968660b19cc3d7e95c6--