CVQ of net vhost-vdpa devices can be intercepted since the work of [1]. The virtio-net device model is updated. The migration was blocked because although the state can be megrated between VMM it was not possible to restore on the destination NIC.
This series add support for SVQ to inject external messages without the guest's knowledge, so before the guest is resumed all the guest visible state is restored. It is done using standard CVQ messages, so the vhost-vdpa device does not need to learn how to restore it: As long as they have the feature, they know how to handle it. This series needs SVQ CVQ support [1] and fixes [2] to be applied. Thanks! [1] https://lists.nongnu.org/archive/html/qemu-devel/2022-07/msg02938.html [2] https://lists.nongnu.org/archive/html/qemu-devel/2022-07/msg02984.html v2: - Fix SIGSEGV dereferencing SVQ when not in svq mode v1 from RFC: - Do not reorder DRIVER_OK & enable patches. - Delete leftovers Eugenio Pérez (5): vhost: stop transfer elem ownership in vhost_handle_guest_kick vdpa: Extract vhost_vdpa_net_cvq_add from vhost_vdpa_net_handle_ctrl_avail vdpa: Make vhost_vdpa_net_cvq_map_elem accept any out sg vdpa: Add virtio-net mac address via CVQ at start vdpa: Delete CVQ migration blocker include/hw/virtio/vhost-vdpa.h | 1 - include/net/vhost-vdpa.h | 1 + hw/net/vhost_net.c | 8 ++ hw/virtio/vhost-shadow-virtqueue.c | 10 +- hw/virtio/vhost-vdpa.c | 11 -- net/vhost-vdpa.c | 162 +++++++++++++++++++++-------- 6 files changed, 132 insertions(+), 61 deletions(-) -- 2.31.1
