It was a mistake to forbid in all cases, as SVQ is already able to send
all the CVQ messages before start forwarding data vqs. It actually
caused a regression, making impossible to migrate device previously
migratable.
Fixes: 36e4647247f2 ("vdpa: add vhost_vdpa_net_valid_svq_features")
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
---
net/vhost-vdpa.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c
index 37cdc84562..c63456ff7c 100644
--- a/net/vhost-vdpa.c
+++ b/net/vhost-vdpa.c
@@ -837,13 +837,16 @@ static NetClientState *net_vhost_vdpa_init(NetClientState *peer,
s->vhost_vdpa.shadow_vq_ops_opaque = s;
/*
- * TODO: We cannot migrate devices with CVQ as there is no way to set
- * the device state (MAC, MQ, etc) before starting the datapath.
+ * TODO: We cannot migrate devices with CVQ and no x-svq enabled as
+ * there is no way to set the device state (MAC, MQ, etc) before
+ * starting the datapath.
*
* Migration blocker ownership now belongs to s->vhost_vdpa.
*/
- error_setg(&s->vhost_vdpa.migration_blocker,
- "net vdpa cannot migrate with CVQ feature");
+ if (!svq) {
+ error_setg(&s->vhost_vdpa.migration_blocker,
+ "net vdpa cannot migrate with CVQ feature");
+ }
}
ret = vhost_vdpa_add(nc, (void *)&s->vhost_vdpa, queue_pair_index, nvqs);
if (ret) {
--
2.31.1