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

[Sean Christopherson <seanjc@google.com>]

On Mon, Feb 23, 2026, Kai Huang wrote:
> On Mon, 2026-02-23 at 08:54 -0800, Sean Christopherson wrote:
> > On Mon, Feb 23, 2026, Kai Huang wrote:
> > > But the odd is if the fault->addr is L2 GPA or L2 GVA, then the shared bit
> > > (which is concept of L1 guest) doesn't apply to it.
> > > 
> > > Btw, from hardware's point of view, does EPT/NPT silently drops high
> > > unmappable bits of GPA or it generates some kinda EPT violation/misconfig?
> > 
> > EPT violation.  The SDM says:
> > 
> >   With 4-level EPT, bits 51:48 of the guest-physical address must all be zero;
> >   otherwise, an EPT violation occurs (see Section 30.3.3).
> > 
> > I can't find anything in the APM (shocker, /s) that clarifies the exact NPT
> > behavior.  It barely even alludes to the use of hCR4.LA57 for controlling the
> > depth of the walk.  But I'm fairly certain NPT behaves identically.
> 
> Then in case of nested EPT (ditto for NPT), shouldn't L0 emulate an VMEXIT
> to L1 if fault->addr exceeds mappable bits?

Huh.  Yes, for sure.  I was expecting FNAME(walk_addr_generic) to handle that,
but AFAICT it doesn't.  Assuming I'm not missing something, that should be fixed
before landing this patch, otherwise I believe KVM would terminate the entire VM
if L2 accesses memory that L1 can't map.