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@xxxxxxxxxx> > > > > > > [ 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
