Re: [PATCH] KVM: x86/mmu: Don't create SPTEs for addresses that aren't mappable

[Sean Christopherson]

On Mon, Feb 23, 2026, Rick P Edgecombe wrote:
> On Fri, 2026-02-20 at 16:49 -0800, Sean Christopherson wrote:
> > > But also the '5' case is weird because as a GVA the max addresse
> > > bits should be 57 and a GPA is should be 54.
> > 
> > 52, i.e. the architectural max MAXPHYADDR.
> 
> Oops yes I meant 52. But if it is always max physical address and not
> trying to handle VA's too, why is PT32E_ROOT_LEVEL 32 instead of
> 36?

Setting aside how any nNPT with a 32-bit kernel works for the moment, it would
be 52, not 36.  PT32E_ROOT_LEVEL is PAE, which per the SDM can address 52 bits
of physical address space:

  PAE paging translates 32-bit linear addresses to 52-bit physical addresses.

PSE-36, a.k.a. 2-level 32-bit paging with CR4.PSE=1, is the horror that can
address 36 bits of physical address space by abusing reserved bits in the "offset"
portion of a huge 4MiB page.

Somewhat of an aside, KVM always uses 64-bit paging or PAE paging for its MMU
(or EPT, but that's basically 64-bit), and so when running on 32-bit kernel, KVM
requires a PAE-enabled kernel to enable NPT, because hCR4 isn't changed on VMRUN,
i.e. the paging mode for KVM's MMU is tightly coupled to the host kernel's paging
mode.  Which is one of several reasons why nNPT is a mess.

  
  	/*
	 * KVM's MMU doesn't support using 2-level paging for itself, and thus
	 * NPT isn't supported if the host is using 2-level paging since host
	 * CR4 is unchanged on VMRUN.
	 */
	if (!IS_ENABLED(CONFIG_X86_64) && !IS_ENABLED(CONFIG_X86_PAE))
		npt_enabled = false;


As for how running a 32-bit PAE nNPT "works", I suspect it simply doesn't from an
architectural perspective.  32-bit KVM-on-KVM works (though I haven't check in a
few years...) because Linux doesn't allocate kernel memory out of high memory,
i.e. L1 KVM won't feed "bad" addresses to L0 KVM, and presumably QEMU doesn't
manage to either.

I might be forgetting something though?  If I get bored, or more likely when my
curiousity gets the best of me, I'll see how hardware behaves.