On Wed, Mar 27, 2019 at 3:05 PM Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > Hmm. I think we could squeak by without it on a technicality. Nested > VMX was only enabled by default after the bug was introduced. Any > migration from an older KVM that "officially" supports nested VMX will > crash the guest ater migration regardless of the target KVM, since KVM > will signal a #GP on RSM due to CR4.VMXE=1 in the SMM save state area. > I.e. it wouldn't break anything that wasn't already broken. > > Toggling HF_SMM_MASK wouldn't suffer the same fate, i.e. new KVMs would > happily accept migration from broken KVMs. That being said, the only > way that can happen is if migration is triggered during the first SMI > with CR4.VMXE=1, since the guest will have already crashed due to RSM > taking a #GP in the broken pre-migration KVM. Given this is the first > bug report for the RSM w/ CR4.VMXE=1, I'm going to go out on a limb and > say that the migration corner case is extremely unlikely, to put it mildly. > > So I think we're good? Maybe add an errata in the docs to note the > extremely unlikely corner case? Yeah, probably. Who's using virtual SMM, anyway? :-) I don't see any tests of virtual SMM in either kvm-unit-tests or tools/testing/selftests/kvm, but maybe I'm not looking closely enough.
