[Qemu-devel] Bug in virtio_net_load

[Robin Geuze]

Hey,

I work for TransIP and we host a VPS platform based on QEMU/KVM. We are 
currently running qemu 2.4.0. A few days ago we noticed that live 
migrations for some of our VM's would fail. Further investigation turned 
out it was specific to windows server 2012, caused by the fact that the 
standard virtio driver from RedHat was replaced in windows updates by a 
driver called "Midfin eFabric" (this driver doesn't really seem to be 
meant for virtio, we have a case running at MicroSoft about that).  Once 
we knew how to reproduce we tested this on  QEMU 2.6.0 as well and it 
also seems to be affected (later we found out that 2.4.0 to 2.6.0 
migration does work probably due to pure luck).

We started investigating the problem in QEMU 2.4.0 and noticed it was 
caused by the fact that virtio_net_device_load requires certain feature 
flags to be set, specifically to load curr_guest_offloads which is only 
written and read if the VIRTIO_NET_F_CTRL_GUEST_OFFLOADS flag is set, 
but those flags are set in virtio_load after the call to 
virtio_net_device_load. Moving the code setting the feature flags before 
the call to virtio_net_device_load fixes it, however it introduces 
another problem. Virtio can have 64-bits feature flags, however the 
standard save payload for virtio only has space for 32-bits feature 
flags. This was solved by putting those in a subsection of the 
vmstate_save_state stuff. Unfortunately this is called (and thus binary 
offset located) after the virtio_net_device_load code.

There was an attempt to fix this in QEMU 2.6.0. However, this seems to 
have broken it worse. The write code (virtio_net_save, virtio_save and 
virtio_net_save_device) still puts the curr_guest_offloads value before 
the vmstate_save_state data. However the read code expects and tries to 
read it after the vmstate_save_state data. Should we just also change 
the virtio_net_save code to have it follow the same order as 
virtio_net_load? Or will this potentially break more stuff.

Regards,

Robin Geuze

TransIP BV