On Fri, Feb 26, 2021 at 12:27:49PM +0100, Paolo Bonzini wrote:
On 26/02/21 12:03, Thomas Lamprecht wrote:
On 04.01.21 16:57, Greg Kroah-Hartman wrote:
From: Paolo Bonzini pbonzini@redhat.com
[ Upstream commit 6441fa6178f5456d1d4b512c08798888f99db185 ]
If the guest is configured to have SPEC_CTRL but the host does not (which is a nonsensical configuration but these are not explicitly forbidden) then a host-initiated MSR write can write vmx->spec_ctrl (respectively svm->spec_ctrl) and trigger a #GP when KVM tries to restore the host value of the MSR. Add a more comprehensive check for valid bits of SPEC_CTRL, covering host CPUID flags and, since we are at it and it is more correct that way, guest CPUID flags too.
For AMD, remove the unnecessary is_guest_mode check around setting the MSR interception bitmap, so that the code looks the same as for Intel.
A git bisect between 5.4.86 and 5.4.98 showed that this breaks boot of QEMU guests running Windows 10 20H2 on AMD Ryzen X3700 CPUs with a BSOD showing "KERNEL SECURITY CHECK FAILURE".
Reverting this commit or setting the CPU type of the QEMU/KVM command from host to qemu64 allows one to boot Windows 10 in the VM again.
I found a followup, commit 841c2be09fe4f495fe5224952a419bd8c7e5b455 [0], which has a fixes line for this commit and mentions Zen2 AMD CPUs (which the X3700 is). Applying a backport of that commit on top of 5.4.98 stable tree fixed the issue here see below for the backport I used, it applies also cleanly on the more current 5.4.101 release.
So can you please add this patch to the stable trees that backported the problematic upstream commit 6441fa6178f5456d1d4b512c08798888f99db185 ?
If I should submit this in any other way just ask, was not sure about what works best with a patch which cannot be cherry-picked cleanly.
Ok, I'll submit it.
Thanks for the testing.
Does that mean I should not take the patch here in this email and that you will submit it after some timeperiod, or that I should take this patch as-is?
thanks,
greg k-h