On Fri, Oct 10, 2025 at 9:39 AM Jason Wang <[email protected]> wrote: > > On Thu, Oct 2, 2025 at 6:36 PM Eugenio Pérez <[email protected]> wrote: > > > > Even if the device supports more than one class, there are ways to solve > > the ambiguity of which device are we creating. In the VDUSE case it is > > the name, for example. > > This may only work for VDUSE but not other parents. > > > > > RFC: I fon't understand 100% the motivation of this limitation, as the > > backend should be the one filtering out the invalid features if any. > > I think we can avoid these tricks. Currently, there's a one single > mgmt device, this seems to be in-convenient. Could we have a per > device mgmt device? For example, if user space creates vduse0, vdpa > mgmtdev show may see vduse0 so we won't have this issue.
Or if we specify the class, there won't be ambiguity. Thanks > > > > > Signed-off-by: Eugenio Pérez <[email protected]> > > --- > > drivers/vdpa/vdpa.c | 9 --------- > > 1 file changed, 9 deletions(-) > > > > diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c > > index 34874beb0152..0fc32f3bd66f 100644 > > --- a/drivers/vdpa/vdpa.c > > +++ b/drivers/vdpa/vdpa.c > > @@ -688,15 +688,6 @@ static int vdpa_nl_cmd_dev_add_set_doit(struct sk_buff > > *skb, struct genl_info *i > > err = -EINVAL; > > goto err; > > } > > - if (!(config.mask & VDPA_DEV_NET_ATTRS_MASK) && > > - config.mask & BIT_ULL(VDPA_ATTR_DEV_FEATURES) && > > - classes & BIT_ULL(VIRTIO_ID_NET) && ncls > 1 && > > - config.device_features & VIRTIO_DEVICE_F_MASK) { > > - NL_SET_ERR_MSG_MOD(info->extack, > > - "Management device supports multi-class > > while device features specified are ambiguous"); > > - err = -EINVAL; > > - goto err; > > - } > > > > err = mdev->ops->dev_add(mdev, name, &config); > > err: > > -- > > 2.51.0 > > > > Thanks
