Re: [PATCH] KVM: x86/mmu: Don't create SPTEs for addresses that aren't mappable
From: Sean Christopherson
Date: Mon Feb 23 2026 - 11:55:11 EST
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.