On Fri, Oct 10, 2025 at 6:40 AM Si-Wei Liu <[email protected]> wrote: > > > > 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? >
Maxime can expand on this, but the user of the vdpa command should not need to know if the backend device is VDUSE, HW, or other device: It should just call the vdpa command the same way, and expect the same results. That also implies that it should handle the same way if a HW device has its own MAC address and then you set a different one with the vdpa command, but device_featues just came first in the pending list :).
