On Tue, Nov 12, 2024, H. Peter Anvin wrote:
> On 11/12/24 10:05, Sean Christopherson wrote:
> > >
> > > Fixes: ea4290d77bda ("KVM: x86: leave kvm.ko out of the build if no vendor module is requested")
> > > Reported-by: kernel test robot <lkp@xxxxxxxxx>
> > > Closes: https://lore.kernel.org/oe-kbuild-all/202410060426.e9Xsnkvi-lkp@xxxxxxxxx/
> > > Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> > > ---
> > > Question: is there actually any point in keeping KVM support for 32-bit host
> > > processors?
> >
> > Nope. We need _a_ 32-bit KVM build to run as a nested (L1) hypervisor for testing
> > purposes, but AFAIK there's zero need to keep 32-bit KVM up-to-date.
>
> What do you mean here? Running an old kernel with the 32-bit KVM in a VM for
> testing the L0 hypervisor?
Yep, to validate nested NPT (NPT is AMD/SVM's stage-2 paging mechanism). Unlike
EPT, which is completely disassociated from the host's CPU mode, NPT is tightly
coupled to the host mode and uses/supports all of the flavors of stage-1 paging,
i.e. legacy 32-bit, PSE, PAE, 4-level, and 5-level.
Because there's no architectural way to prevent L1 from using 32-bit or PAE NPT,
KVM needs to support shadowing such NPT tables. And so to validate that KVM (L0)
correctly shadows L1's NPT tables, we need a 32-bit hypervisor to run in L1. We
briefly considered writing dedicated tests, but the effort required is absurd,
relatively to the coverage provided.
It's quite annoying, because I highly doubt anyone actually uses 32-bit hypervisors
of any flavor, but nested NPT allows for some truly unique setups, e.g. where KVM
is using 5-level NPT to shadow legacy 3-level 32-bit page tables. As a result,
KVM has paths are only reachable with a 32-bit L1 KVM, and at the very least we
need to ensure they aren't juicy attack vectors.
