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

[Huang, Kai]

On Mon, 2026-02-23 at 13:25 -0800, Sean Christopherson wrote:
> 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.  
> 

AFAICT too.  It goes to page table walk directly w/o checking beforehand.

> 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.

Yeah agreed.