On Fri, Sep 04, 2026 at 01:20:44PM +0100, Fuad Tabba wrote: > On Fri, 4 Sept 2026 at 12:48, Mark Brown 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.