On Mon, Jun 06, 2022 at 06:18:12PM +0200, Paolo Bonzini wrote:
However there seems to be something missing at least to me, on why it'll fail a migration from 5.15 (without this patch) to 5.18 (with this patch). In my test case, user_xfeatures will be 0x7 (FP|SSE|YMM) if without this patch, but 0x0 if with it.
What CPU model are you using for the VM?
I didn't specify it, assuming it's qemu64 with no extra parameters.
I just tried two other options with: (1) -cpu host, and (2) -cpu Haswell (the choice of Haswell was really random..), with the same 5.15->5.18 migration scenario, both of them will not trigger the same guest kernel crash. Only qemu64 will.
Both hosts have Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz.
For example, if the source lacks this patch but the destination has it, the source will transmit YMM registers, but the destination will fail to set them if they are not available for the selected CPU model.
See the commit message: "As a bonus, it will also fail if userspace tries to set fpu features (with the KVM_SET_XSAVE ioctl) that are not compatible to the guest configuration. Such features will never be returned by KVM_GET_XSAVE or KVM_GET_XSAVE2."
IIUC you meant we should have failed KVM_SET_XSAVE when they're not aligned (probably by failing validate_user_xstate_header when checking against the user_xfeatures on dest host). But that's probably not my case, because here KVM_SET_XSAVE succeeded, it's just that the guest gets a double fault after the precopy migration completes (or for postcopy when the switchover is done).
Thanks,