Next patches enable devices to be migrated even if vdpa netdev has not
been started with x-svq. However, not all devices are migratable, so we
need to block migration if we detect that.
Block migration if we detect the device expose a feature SVQ does not
know how to work with.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <
20230303172445.
1089785-13-eperezma@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
return 0;
}
+ /*
+ * If dev->shadow_vqs_enabled at initialization that means the device has
+ * been started with x-svq=on, so don't block migration
+ */
+ if (dev->migration_blocker == NULL && !v->shadow_vqs_enabled) {
+ /* We don't have dev->features yet */
+ uint64_t features;
+ ret = vhost_vdpa_get_dev_features(dev, &features);
+ if (unlikely(ret)) {
+ error_setg_errno(errp, -ret, "Could not get device features");
+ return ret;
+ }
+ vhost_svq_valid_features(features, &dev->migration_blocker);
+ }
+
/*
* Similar to VFIO, we end up pinning all guest memory and have to
* disable discarding of RAM.