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

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