[RFC PATCH v5 036/104] KVM: x86/mmu: Explicitly check for MMIO spte in fast page fault

isaku.yamahata@intel.com posted 104 patches 3 years, 9 months ago
There is a newer version of this series
[RFC PATCH v5 036/104] KVM: x86/mmu: Explicitly check for MMIO spte in fast page fault
Posted by isaku.yamahata@intel.com 3 years, 9 months ago
From: Sean Christopherson <sean.j.christopherson@intel.com>

Explicitly check for an MMIO spte in the fast page fault flow.  TDX will
use a not-present entry for MMIO sptes, which can be mistaken for an
access-tracked spte since both have SPTE_SPECIAL_MASK set.

The fast page fault handles the case of changing access bits without
obtaining mmu_lock.  For example, clear write protect bit for dirty page
tracking.  MMIO emulation is handled in a slow path.  So it doesn't affect
the default VM case.

Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
---
 arch/x86/kvm/mmu/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index b68191aa39bf..9907cb759fd1 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3167,7 +3167,7 @@ static int fast_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
 			break;
 
 		sp = sptep_to_sp(sptep);
-		if (!is_last_spte(spte, sp->role.level))
+		if (!is_last_spte(spte, sp->role.level) || is_mmio_spte(spte))
 			break;
 
 		/*
-- 
2.25.1
Re: [RFC PATCH v5 036/104] KVM: x86/mmu: Explicitly check for MMIO spte in fast page fault
Posted by Paolo Bonzini 3 years, 8 months ago
On 3/4/22 20:48, isaku.yamahata@intel.com wrote:
> From: Sean Christopherson <sean.j.christopherson@intel.com>
> 
> Explicitly check for an MMIO spte in the fast page fault flow.  TDX will
> use a not-present entry for MMIO sptes, which can be mistaken for an
> access-tracked spte since both have SPTE_SPECIAL_MASK set.
> 
> The fast page fault handles the case of changing access bits without
> obtaining mmu_lock.  For example, clear write protect bit for dirty page
> tracking.  MMIO emulation is handled in a slow path.  So it doesn't affect

"MMIO sptes are handled in handle_mmio_page_fault for non-TDX VMs, so 
this patch does not affect them.  TDX will handle MMIO emulation through 
a hypercall instead".

For this comment, it is not necessary to talk about the slow path, since 
that is just where MMIO sptes are installed.  If the slow path is 
reached, fast_page_fault must not have seen is_mmio_spte(spte).

> @@ -3167,7 +3167,7 @@ static int fast_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
>   			break;
>   
>   		sp = sptep_to_sp(sptep);
> -		if (!is_last_spte(spte, sp->role.level))
> +		if (!is_last_spte(spte, sp->role.level) || is_mmio_spte(spte))
>   			break;
>   
>   		/*

I would include the check a couple lines before:

	if (!is_shadow_present_pte(spte) || is_mmio_spte(spte))

This matches what is in the commit message: the problem is that MMIO 
SPTEs are present in the TDX case, so you need to check them even if 
is_shadow_present_pte(spte) returns true.

Paolo