On 27/03/19 23:14, Jim Mattson 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? :-) Anyone that is using DOS with versions of SeaBIOS that run 32-bit drives in SMM. :) But yeah, there is no way that this can ever have worked so we can fix the API. Paolo > 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.
