search for: vhost_backend_f_suspend

Displaying 9 results from an estimated 9 matches for "vhost_backend_f_suspend".

2023 Sep 09
0
[PATCH RFC v2 2/3] vhost-vdpa: introduce descriptor group backend feature
...vice *vdpa = v->vdpa; @@ -679,6 +687,7 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep, if (copy_from_user(&features, featurep, sizeof(features))) return -EFAULT; if (features & ~(VHOST_VDPA_BACKEND_FEATURES | + BIT_ULL(VHOST_BACKEND_F_DESC_ASID) | BIT_ULL(VHOST_BACKEND_F_SUSPEND) | BIT_ULL(VHOST_BACKEND_F_RESUME))) return -EOPNOTSUPP; @@ -688,6 +697,12 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep, if ((features & BIT_ULL(VHOST_BACKEND_F_RESUME)) && !vhost_vdpa_can_resume(v)) return -EOPNOTSUPP; + if ((features & BIT_...
2023 Feb 23
0
[PATCH v2 11/13] vdpa: block migration if dev does not have _F_SUSPEND
...p;backend_features); >>> + if (unlikely(ret)) { >>> + error_setg_errno(errp, -ret, "Could not get backend features"); >>> + return ret; >>> + } >>> + >>> + if (!(backend_features & BIT_ULL(VHOST_BACKEND_F_SUSPEND))) { >>> + error_setg(&dev->migration_blocker, >>> + "vhost-vdpa backend lacks VHOST_BACKEND_F_SUSPEND feature."); >>> + } >> >> I wonder why not let the device to decide? For networking device, we can >>...
2023 Jul 03
0
[PATCH] vdpa: reject F_ENABLE_AFTER_DRIVER_OK if backend does not support it
...ND_FEATURES) { > if (copy_from_user(&features, featurep, sizeof(features))) > return -EFAULT; > + if (ops->get_backend_features) > + parent_features = ops->get_backend_features(v->vdpa); > if (features & ~(VHOST_VDPA_BACKEND_FEATURES | > BIT_ULL(VHOST_BACKEND_F_SUSPEND) | > BIT_ULL(VHOST_BACKEND_F_RESUME) | > - BIT_ULL(VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK))) > + parent_features)) > return -EOPNOTSUPP; > if ((features & BIT_ULL(VHOST_BACKEND_F_SUSPEND)) && > !vhost_vdpa_can_suspend(v)) > -- > 2.39...
2023 Jul 04
1
[PATCH] vdpa: reject F_ENABLE_AFTER_DRIVER_OK if backend does not support it
...AULT; > > > + if (ops->get_backend_features) > > > + parent_features = ops->get_backend_features(v->vdpa); > > > if (features & ~(VHOST_VDPA_BACKEND_FEATURES | > > > BIT_ULL(VHOST_BACKEND_F_SUSPEND) | > > > BIT_ULL(VHOST_BACKEND_F_RESUME) | > > > - BIT_ULL(VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK))) > > > + parent_features)) > > > return -EOPNOTSUPP;...
2023 Jul 04
1
[PATCH] vdpa: reject F_ENABLE_AFTER_DRIVER_OK if backend does not support it
...if (ops->get_backend_features) > > > > > + parent_features = ops->get_backend_features(v->vdpa); > > > > > if (features & ~(VHOST_VDPA_BACKEND_FEATURES | > > > > > BIT_ULL(VHOST_BACKEND_F_SUSPEND) | > > > > > BIT_ULL(VHOST_BACKEND_F_RESUME) | > > > > > - BIT_ULL(VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK))) > > > > > + parent_features)) > > > > >...
2023 Sep 09
4
[PATCH RFC v2 0/3] vdpa: dedicated descriptor table group
Following patchset introduces dedicated group for descriptor table to reduce live migration downtime when passthrough VQ is being switched to shadow VQ. This RFC v2 is sent to incorporate the early feedback from reviewers on the uAPI and driver API part of changes, the associated driver patch set consuming ths API will come around soon along with formal submission of this series. Some initial
2023 Feb 16
0
[PATCH v3 04/14] vdpa: add vhost_vdpa_suspend
...a_svqs_stop(struct vhost_dev *dev) > } > } > > +static void vhost_vdpa_suspend(struct vhost_dev *dev) > +{ > + struct vhost_vdpa *v = dev->opaque; > + int r; > + > + if (!vhost_vdpa_first_dev(dev) || > + !(dev->backend_features & BIT_ULL(VHOST_BACKEND_F_SUSPEND))) { Shouldn't it be backend_cap?
2023 Sep 09
4
[PATCH RFC v2 0/4] vdpa: decouple reset of iotlb mapping from device reset
In order to reduce needlessly high setup and teardown cost of iotlb mapping during live migration, it's crucial to decouple the vhost-vdpa iotlb abstraction from the virtio device life cycle, i.e. iotlb mappings should be left intact across virtio device reset [1]. For it to work, the on-chip IOMMU parent device should implement a separate .reset_map() operation callback to restore 1:1 DMA
2023 Sep 09
4
[PATCH RFC v3 0/4] vdpa: decouple reset of iotlb mapping from device reset
In order to reduce needlessly high setup and teardown cost of iotlb mapping during live migration, it's crucial to decouple the vhost-vdpa iotlb abstraction from the virtio device life cycle, i.e. iotlb mappings should be left intact across virtio device reset [1]. For it to work, the on-chip IOMMU parent device should implement a separate .reset_map() operation callback to restore 1:1 DMA