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

[Huang, Kai]

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

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? 
I tried to confirm from the spec but seems not sure.