linux-kernel - Re: [REGRESSION] from 74a0e79df68a8042fb84fd7207e57b70722cf825: VFIO PCI passthrough no longer works

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z1hiiz40nUqN2e5M@google.com>
Date: Tue, 10 Dec 2024 07:47:23 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Simon Pilkington <simonp.git@...lbox.org>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org, 
	regressions@...ts.linux.dev, Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [REGRESSION] from 74a0e79df68a8042fb84fd7207e57b70722cf825: VFIO
 PCI passthrough no longer works

+Tom

On Tue, Dec 10, 2024, Simon Pilkington wrote:
> Hi,
> 
> With the aforementioned commit I am no longer able to use PCI passthrough to
> a Windows guest on the X570 chipset with a 5950X CPU.
> 
> The minimal reproducer for me is to attach a GPU to the VM and attempt to
> start Windows setup from an iso image. The VM will apparently livelock at the
> setup splash screen before the spinner appears as one of my CPU cores goes up
> to 100% usage until I force off the VM. This could be very machine-specific
> though.

Ugh.  Yeah, it's pretty much guaranteed to be CPU specific behavior.

Tom, any idea what the guest might be trying to do?  It probably doesn't matter
in the end, it's not like KVM does anything with the value...

> Reverting to the old XOR check fixes both 6.12.y stable and 6.13-rc2 for me.
> Otherwise they're both bad. Can you please look into it? I can share the
> config I used for test builds if it would help.

Can you run with the below to see what bits the guest is trying to set (or clear)?
We could get the same info via tracepoints, but this will likely be faster/easier.

---
 arch/x86/kvm/svm/svm.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index dd15cc635655..5144d0283c9d 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3195,11 +3195,14 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr)
 	case MSR_AMD64_DE_CFG: {
 		u64 supported_de_cfg;
 
-		if (svm_get_feature_msr(ecx, &supported_de_cfg))
+		if (WARN_ON_ONCE(svm_get_feature_msr(ecx, &supported_de_cfg)))
 			return 1;
 
-		if (data & ~supported_de_cfg)
+		if (data & ~supported_de_cfg) {
+			pr_warn("DE_CFG supported = %llx, WRMSR = %llx\n",
+				supported_de_cfg, data);
 			return 1;
+		}
 
 		/*
 		 * Don't let the guest change the host-programmed value.  The
@@ -3207,8 +3210,11 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr)
 		 * are completely unknown to KVM, and the one bit known to KVM
 		 * is simply a reflection of hardware capabilities.
 		 */
-		if (!msr->host_initiated && data != svm->msr_decfg)
+		if (!msr->host_initiated && data != svm->msr_decfg) {
+			pr_warn("DE_CFG current = %llx, WRMSR = %llx\n",
+				svm->msr_decfg, data);
 			return 1;
+		}
 
 		svm->msr_decfg = data;
 		break;

base-commit: fac04efc5c793dccbd07e2d59af9f90b7fc0dca4
--