At the moment qemu block the migration as long as the vdpa device offers
features not supported by SVQ. VIRTIO_NET_F_HOST_USO is not even
offered to the guest, since qemu emulated devices does not support it,
and we know for sure it will require no changes on SVQ code when
supported. For that reason, lift the block on this feature.
In a future this blocker could be smarter, and ignore features that are
never offered to the guest either because is disabled in the cmdline
(like mq=off) or it is not even supported.
Tested-by: Alvaro Karsz <alvaro.ka...@solid-run.com>
Signed-off-by: Eugenio Pérez <epere...@redhat.com>
---
net/vhost-vdpa.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c
index 99904a0da7..ff67babd23 100644
--- a/net/vhost-vdpa.c
+++ b/net/vhost-vdpa.c
@@ -103,6 +103,7 @@ static const uint64_t vdpa_svq_device_features =
BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR) |
/* VHOST_F_LOG_ALL is exposed by SVQ */
BIT_ULL(VHOST_F_LOG_ALL) |
+ BIT_ULL(VIRTIO_NET_F_HOST_USO) |
BIT_ULL(VIRTIO_NET_F_RSC_EXT) |
BIT_ULL(VIRTIO_NET_F_STANDBY);
--
2.31.1
