diff mbox series

[v19,018/130] KVM: x86/mmu: Assume guest MMIOs are shared

Message ID b2e5c92fd66a0113b472dd602220346d3d435732.1708933498.git.isaku.yamahata@intel.com (mailing list archive)
State New, archived
Headers show
Series [v19,001/130] x86/virt/tdx: Rename _offset to _member for TD_SYSINFO_MAP() macro | expand

Commit Message

Isaku Yamahata Feb. 26, 2024, 8:25 a.m. UTC
From: Chao Gao <chao.gao@intel.com>

TODO: Drop this patch once the common patch is merged.

When memory slot isn't found for kvm page fault, handle it as MMIO.

The guest of TDX_VM, SNP_VM, or SW_PROTECTED_VM don't necessarily convert
the virtual MMIO range to shared before accessing it.  When the guest tries
to access the virtual device's MMIO without any private/shared conversion,
An NPT fault or EPT violation is raised first to find private-shared
mismatch.  Don't raise KVM_EXIT_MEMORY_FAULT, fall back to KVM_PFN_NOLSLOT.

Signed-off-by: Chao Gao <chao.gao@intel.com>
Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
---
v19:
- Added slot check before kvm_faultin_private_pfn()
- updated comment
- rewrite the commit message
---
 arch/x86/kvm/mmu/mmu.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

Comments

Edgecombe, Rick P March 25, 2024, 11:41 p.m. UTC | #1
On Mon, 2024-02-26 at 00:25 -0800, isaku.yamahata@intel.com wrote:
> From: Chao Gao <chao.gao@intel.com>
> 
> TODO: Drop this patch once the common patch is merged.

What is this TODO talking about?

> 
> When memory slot isn't found for kvm page fault, handle it as MMIO.
> 
> The guest of TDX_VM, SNP_VM, or SW_PROTECTED_VM don't necessarily convert
> the virtual MMIO range to shared before accessing it.  When the guest tries
> to access the virtual device's MMIO without any private/shared conversion,
> An NPT fault or EPT violation is raised first to find private-shared
> mismatch.  Don't raise KVM_EXIT_MEMORY_FAULT, fall back to KVM_PFN_NOLSLOT.

If this is general KVM_X86_SW_PROTECTED_VM behavior, can we pull it out of the TDX series?

> 
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
> ---
Isaku Yamahata March 27, 2024, 5:22 p.m. UTC | #2
On Mon, Mar 25, 2024 at 11:41:56PM +0000,
"Edgecombe, Rick P" <rick.p.edgecombe@intel.com> wrote:

> On Mon, 2024-02-26 at 00:25 -0800, isaku.yamahata@intel.com wrote:
> > From: Chao Gao <chao.gao@intel.com>
> > 
> > TODO: Drop this patch once the common patch is merged.
> 
> What is this TODO talking about?

https://lore.kernel.org/all/ZcUO5sFEAIH68JIA@google.com/

This patch was shot down and need to fix it in guest side. TDVF.
Edgecombe, Rick P March 27, 2024, 5:27 p.m. UTC | #3
On Wed, 2024-03-27 at 10:22 -0700, Isaku Yamahata wrote:
> On Mon, Mar 25, 2024 at 11:41:56PM +0000,
> "Edgecombe, Rick P" <rick.p.edgecombe@intel.com> wrote:
> 
> > On Mon, 2024-02-26 at 00:25 -0800, isaku.yamahata@intel.com wrote:
> > > From: Chao Gao <chao.gao@intel.com>
> > > 
> > > TODO: Drop this patch once the common patch is merged.
> > 
> > What is this TODO talking about?
> 
> https://lore.kernel.org/all/ZcUO5sFEAIH68JIA@google.com/
> 
> This patch was shot down and need to fix it in guest side. TDVF.

It needs a firmware fix? Is there any firmware that works (boot any TD) with this patch missing?
Isaku Yamahata April 4, 2024, 10:31 p.m. UTC | #4
On Wed, Mar 27, 2024 at 05:27:52PM +0000,
"Edgecombe, Rick P" <rick.p.edgecombe@intel.com> wrote:

> On Wed, 2024-03-27 at 10:22 -0700, Isaku Yamahata wrote:
> > On Mon, Mar 25, 2024 at 11:41:56PM +0000,
> > "Edgecombe, Rick P" <rick.p.edgecombe@intel.com> wrote:
> > 
> > > On Mon, 2024-02-26 at 00:25 -0800, isaku.yamahata@intel.com wrote:
> > > > From: Chao Gao <chao.gao@intel.com>
> > > > 
> > > > TODO: Drop this patch once the common patch is merged.
> > > 
> > > What is this TODO talking about?
> > 
> > https://lore.kernel.org/all/ZcUO5sFEAIH68JIA@google.com/
> > 
> > This patch was shot down and need to fix it in guest side. TDVF.
> 
> It needs a firmware fix? Is there any firmware that works (boot any TD) with this patch missing?

Yes.  Config-B (OvmfPkg/IntelTdx/IntelTdxX64.dsc) works for me without this patch.
I'm looking into config-A(OvmfPkg/OvmfPkgX64.dsc) now.
diff mbox series

Patch

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index ca0c91f14063..c45252ed2ffd 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -4342,6 +4342,7 @@  static int kvm_faultin_pfn_private(struct kvm_vcpu *vcpu,
 static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
 {
 	struct kvm_memory_slot *slot = fault->slot;
+	bool force_mmio;
 	bool async;
 
 	/*
@@ -4371,12 +4372,21 @@  static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault
 			return RET_PF_EMULATE;
 	}
 
-	if (fault->is_private != kvm_mem_is_private(vcpu->kvm, fault->gfn)) {
+	/*
+	 * !fault->slot means MMIO for SNP and TDX.  Don't require explicit GPA
+	 * conversion for MMIO because MMIO is assigned at the boot time.  Fall
+	 * to !is_private case to get pfn = KVM_PFN_NOSLOT.
+	 */
+	force_mmio = !slot &&
+		vcpu->kvm->arch.vm_type != KVM_X86_DEFAULT_VM &&
+		vcpu->kvm->arch.vm_type != KVM_X86_SW_PROTECTED_VM;
+	if (!force_mmio &&
+	    fault->is_private != kvm_mem_is_private(vcpu->kvm, fault->gfn)) {
 		kvm_mmu_prepare_memory_fault_exit(vcpu, fault);
 		return -EFAULT;
 	}
 
-	if (fault->is_private)
+	if (!force_mmio && fault->is_private)
 		return kvm_faultin_pfn_private(vcpu, fault);
 
 	async = false;