[PATCH 2/2] KVM: arm64: Enable S1PIE for nVHE and hVHE
Mark Brown
broonie at kernel.org
Fri Sep 4 06:38:07 PDT 2026
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:
> > 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.
> Where I think it applies is kvm-arm.mode=nvhe on S1PIE hardware. That
> boots, and it's the one configuration where the nVHE side of the patch
> would run.
Yes, exactly. As you say any system with S1PIE would only run actual
nNVHE mode if it was requested on the command line. Realistically this
is something that people end up doing relatively often in development
even though it is not useful for production, so as Will said it should
run. It seemed explicitly excluding supporting the nVHE case was more
likely to trip people up one way or another.
Marc also started out with a flat no and didn't mention anything
positive about the hVHE part so it appeared that he was objecting to the
whole concept of the patch, including the hVHE aspect. It seems you and
Will are both OK with the hVHE bit and indifferent to the nVHE case, and
I can certainly rework to unsupport nVHE mode.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260904/43d4e86d/attachment.sig>
More information about the linux-arm-kernel
mailing list