On 10/2/2025 3:35 AM, Eugenio Pérez wrote:
This patch implements features provisioning for vduse devices. This
allows the device provisioner to clear the features exposed by the
userland device, so the driver never see them. The intended use case is
to provision more than one different device with the same feature set,
allowing live migration between them.
The device addition validates the provisioned features to be a subset of
the parent features, as the rest of the backends.
Signed-off-by: Eugenio Pérez <[email protected]>
---
drivers/vdpa/vdpa_user/vduse_dev.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c
b/drivers/vdpa/vdpa_user/vduse_dev.c
index 6c74282d5721..ef8fc795cfeb 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -121,6 +121,7 @@ struct vduse_dev {
bool connected;
u64 api_version;
u64 device_features;
+ u64 supported_features;
u64 driver_features;
u32 device_id;
u32 vendor_id;
@@ -698,7 +699,7 @@ static u64 vduse_vdpa_get_device_features(struct
vdpa_device *vdpa)
{
struct vduse_dev *dev = vdpa_to_vduse(vdpa);
- return dev->device_features;
+ return dev->supported_features;
}
static int vduse_vdpa_set_driver_features(struct vdpa_device *vdpa, u64 features)
@@ -2256,13 +2257,22 @@ struct vduse_mgmt_dev {
static struct vduse_mgmt_dev *vduse_mgmt;
-static int vduse_dev_init_vdpa(struct vduse_dev *dev, const char *name)
+static int vduse_dev_init_vdpa(struct vduse_dev *dev, const char *name,
+ const struct vdpa_dev_set_config *config)
{
struct vduse_vdpa *vdev;
if (dev->vdev)
return -EEXIST;
+ if (config->mask & BIT_ULL(VDPA_ATTR_DEV_FEATURES)) {
+ if (config->device_features & ~dev->device_features)
+ return -EINVAL;
+ dev->supported_features = config->device_features;
+ } else {
+ dev->supported_features = dev->device_features;
+ }
+
Why this feature filter can't be done in the client (library) of vduse
itself, similar to other device specific features of the existing vduse
client? I thought those vduse clients are never managed by vdpa tool,
while the device class can't be bound until client had registered with
vduse. What is the point to define the feature bit in one place, but the
value of the feature (for e.g. mac, mtu) is still or has to be provided
by the client itself? Is it the right behavior to filter features in a
separate layer rather than contain all relevant feature bits and
attributes in one central location?
Regards,
-Siwei
vdev = vdpa_alloc_device(struct vduse_vdpa, vdpa, dev->dev,
&vduse_vdpa_config_ops, &vduse_map_ops,
dev->ngroups, dev->nas, name, true);
@@ -2289,7 +2299,7 @@ static int vdpa_dev_add(struct vdpa_mgmt_dev *mdev, const
char *name,
mutex_unlock(&vduse_lock);
return -EINVAL;
}
- ret = vduse_dev_init_vdpa(dev, name);
+ ret = vduse_dev_init_vdpa(dev, name, config);
mutex_unlock(&vduse_lock);
if (ret)
return ret;
@@ -2376,6 +2386,7 @@ static int vduse_mgmtdev_init(void)
vduse_mgmt->mgmt_dev.id_table = id_table;
vduse_mgmt->mgmt_dev.ops = &vdpa_dev_mgmtdev_ops;
vduse_mgmt->mgmt_dev.device = &vduse_mgmt->dev;
+ vduse_mgmt->mgmt_dev.config_attr_mask = BIT_ULL(VDPA_ATTR_DEV_FEATURES);
ret = vdpa_mgmtdev_register(&vduse_mgmt->mgmt_dev);
if (ret)
device_unregister(&vduse_mgmt->dev);
