[Qemu-devel] QEMU/KVM migration backwards compatibility broken?

[Liran Alon]

Hi,

Looking at QEMU source code, I am puzzled regarding how migration backwards 
compatibility is preserved regarding X86CPU.

As I understand it, fields that are based on KVM capabilities and guest runtime 
usage are defined in VMState subsections in order to not send them if not 
necessary.
This is done such that in case they are not needed and we migrate to an old 
QEMU which don’t support loading this state, migration will still succeed
(As .needed() method will return false and therefore this state won’t be sent 
as part of migration stream).
Furthermore, in case .needed() returns true and old QEMU don’t support loading 
this state, migration fails. As it should because we are aware that guest state
is not going to be restored properly on destination.

I’m puzzled about what will happen in the following scenario:
1) Source is running new QEMU with new KVM that supports save of some VMState 
subsection.
2) Destination is running new QEMU that supports load this state but with old 
kernel that doesn’t know how to load this state.

I would have expected in this case that if source .needed() returns true, then 
migration will fail because of lack of support in destination kernel.
However, it seems from current QEMU code that this will actually succeed in 
many cases.

For example, if msr_smi_count is sent as part of migration stream (See 
vmstate_msr_smi_count) and destination have has_msr_smi_count==false,
then destination will succeed loading migration stream but kvm_put_msrs() will 
actually ignore env->msr_smi_count and will successfully load guest state.
Therefore, migration will succeed even though it should have failed…

It seems to me that QEMU should have for every such VMState subsection, a 
.post_load() method that verifies that relevant capability is supported by 
kernel
and otherwise fail migration.

What do you think? Should I really create a patch to modify all these CPUX86 
VMState subsections to behave like this?

Thanks,
-Liran