SYS-OSS/FRET-qemu
4
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

vdpa: block migration if SVQ does not admit a feature

Browse Source 
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>
This commit is contained in:
Eugenio Pérez 2023-03-03 18:24:43 +01:00 committed by Michael S. Tsirkin
parent 5c1ebd4c43
commit 57ac831865
1 changed files with 15 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
hw/virtio/vhost-vdpa.c
View File

@ -443,6 +443,21 @@ static int vhost_vdpa_init(struct vhost_dev *dev, void *opaque, Error **errp)
return 0; 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 * Similar to VFIO, we end up pinning all guest memory and have to
* disable discarding of RAM. * disable discarding of RAM.