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

[Huang, Kai]

On Mon, 2026-02-23 at 08:54 -0800, Sean Christopherson wrote:
> On Mon, Feb 23, 2026, Kai Huang wrote:
> > 
> > > @@ -3540,6 +3540,14 @@ static int kvm_handle_noslot_fault(struct kvm_vcpu *vcpu,
> > >  	if (unlikely(fault->gfn > kvm_mmu_max_gfn()))
> > >  		return RET_PF_EMULATE;
> > >  
> > > +	/*
> > > +	 * Similarly, if KVM can't map the faulting address, don't attempt to
> > > +	 * install a SPTE because KVM will effectively truncate the address
> > > +	 * when walking KVM's page tables.
> > > +	 */
> > > +	if (unlikely(fault->addr & vcpu->arch.mmu->unmappable_mask))
> > > +		return RET_PF_EMULATE;
> > > +
> > >  	return RET_PF_CONTINUE;
> > >  }
> > >  
> > > @@ -4681,6 +4689,11 @@ static int kvm_mmu_faultin_pfn(struct kvm_vcpu *vcpu,
> > >  		return RET_PF_RETRY;
> > >  	}
> > >  
> > > +	if (fault->addr & vcpu->arch.mmu->unmappable_mask) {
> > > +		kvm_mmu_prepare_memory_fault_exit(vcpu, fault);
> > > +		return -EFAULT;
> > > +	}
> > > +
> > 
> > If we forget the case of shadow paging, do you think we should explicitly
> > strip the shared bit?
> > 
> > I think the MMU code currently always treats the shared bit as "mappable"
> > (as long as the real GPA is mappable), so logically it's better to strip the
> > shared bit first before checking the GPA.  But in practice there's no
> > problem because only TDX uses shared bit and it is within the 'mappable'
> > bits.
> 
> I don't think so?  Because even though the SHARED bit has special semantics, it's
> still very much an address bit in the current architecture.

I guess we can safely assume this is true for Intel.  Not sure for AMD,
though, but AMD doesn't use shared bit in KVM.  Anyway it's safe in
practice.

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