Re: [PATCH 2/2] KVM: arm64: Enable S1PIE for nVHE and hVHE

[Will Deacon]

On Fri, Sep 04, 2026 at 01:20:44PM +0100, Fuad Tabba wrote:
> On Fri, 4 Sept 2026 at 12:48, Mark Brown <broonie@xxxxxxxxxx> wrote:
> >
> > On Fri, Sep 04, 2026 at 12:29:23PM +0100, Will Deacon wrote:
> > > On Fri, Sep 04, 2026 at 11:33:24AM +0100, Mark Brown wrote:
> >
> > > > What about pKVM, my understanding was that that is very much an ongoing
> > > > concern and uses the nVHE hypervisor?  My expectation was that this
> > > > would only ever get used in hVHE configurations when people enable pKVM
> > > > on modern hardware, actual nVHE mode was mostly just carried along with
> > > > that.
> >
> > > pKVM uses hVHE wherever it can nowadays, so I'm fine with only supporting
> > > S1PIE on hVHE and VHE configurations if that's easier to maintain. We
> > > just need to make sure that the failure mode for nVHE results in the
> > > feature being gracefully disabled, rather than e.g. crashing or quietly
> > > doing the wrong thing.
> >
> > I figure that if we're supporting hVHE it will end up less complicated
> > to also enable nVHE, it reduces the potential for having bad or missing
> > fallback paths for features downstream of S1POE.  It's not like it's a
> > huge extra bit of code and it seems likely to save hassle down the line.
> 
> For pKVM there's no fallback path to get wrong: any CPU with S1PIE has
> VHE, so pKVM runs hVHE on it, and a CPU without VHE has no S1PIE to
> disable. I couldn't construct the protected nVHE plus S1PIE case under
> QEMU at all.

I can't remember the exact incantation, but there's definitely a way to
force pKVM + nVHE on VHE-capable hardware on the cmdline. So we should
just make sure that doesn't go horribly wrong!

Will