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

[Alexandru Elisei]

Hi Will,

On Fri, Sep 04, 2026 at 02:41:28PM +0100, Will Deacon wrote:
> On Fri, Sep 04, 2026 at 01:20:44PM +0100, Fuad Tabba wrote:
> > On Fri, 4 Sept 2026 at 12:48, Mark Brown <broonie at kernel.org> 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!

arm64_sw.hvhe=0 id_aa64mmfr1.vh=0

>From kernel-paramters.txt, and last time I checked (two or three kernel versions
ago) it was working.

Thanks,
Ale