Re: [RFC 1/2] vduse: support feature provisioning

Eugenio Perez Martin
2025-10-10T09:41:48Z

On Fri, Oct 10, 2025 at 6:40 AM Si-Wei Liu <si-wei.liu@oracle.com> 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 <eperezma@redhat.com>
> > ---
> > 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 :).