[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Bug in virtio_net_load

From: Robin Geuze
Subject: [Qemu-devel] Bug in virtio_net_load
Date: Thu, 30 Jun 2016 10:34:51 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1


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.


Robin Geuze

TransIP BV

reply via email to

[Prev in Thread] Current Thread [Next in Thread]