Re: [PATCH] x86: kvm: add back X86_LOCAL_APIC dependency

[Sean Christopherson <seanjc@google.com>]

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@intel.com>
> > > Closes: https://lore.kernel.org/oe-kbuild-all/202410060426.e9Xsnkvi-lkp@intel.com/
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > 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.