Re: [PATCH] vdpa: allow provisioning device features

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 11, 2022 at 6:19 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:
>
> On Fri, Nov 11, 2022 at 03:17:14PM +0800, Jason Wang wrote:
> > On Thu, Nov 10, 2022 at 7:01 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Nov 10, 2022 at 03:58:21PM +0800, Jason Wang wrote:
> > > > This patch allows device features to be provisioned via vdpa. This
> > > > will be useful for preserving migration compatibility between source
> > > > and destination:
> > > >
> > > > # vdpa dev add name dev1 mgmtdev pci/0000:02:00.0 device_features 0x300020000
> > > > # dev1: mac 52:54:00:12:34:56 link up link_announce false mtu 65535
> > > >       negotiated_features CTRL_VQ VERSION_1 ACCESS_PLATFORM
> > > >
> > > > Signed-off-by: Jason Wang <jasowang@xxxxxxxxxx>
> > > > ---
> > > >  man/man8/vdpa-dev.8            | 10 ++++++++++
> > > >  vdpa/include/uapi/linux/vdpa.h |  1 +
> > > >  vdpa/vdpa.c                    | 27 ++++++++++++++++++++++++++-
> > > >  3 files changed, 37 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/man/man8/vdpa-dev.8 b/man/man8/vdpa-dev.8
> > > > index 9faf3838..bb45b4a6 100644
> > > > --- a/man/man8/vdpa-dev.8
> > > > +++ b/man/man8/vdpa-dev.8
> > > > @@ -31,6 +31,7 @@ vdpa-dev \- vdpa device configuration
> > > >  .I NAME
> > > >  .B mgmtdev
> > > >  .I MGMTDEV
> > > > +.RI "[ device_features " DEVICE_FEATURES " ]"
> > > >  .RI "[ mac " MACADDR " ]"
> > > >  .RI "[ mtu " MTU " ]"
> > > >  .RI "[ max_vqp " MAX_VQ_PAIRS " ]"
> > > > @@ -74,6 +75,10 @@ Name of the new vdpa device to add.
> > > >  Name of the management device to use for device addition.
> > > >
> > > >  .PP
> > > > +.BI device_features " DEVICE_FEAETURES"
> > >
> > > typo
> >
> > Will fix.
> >
> > >
> > > > +- specifies the device features that is provisioned for the new vdpa device.
> > >
> > > I propose
> > >          the device features -> the virtio "device features" bit-mask
> > >
> > > features sounds like it's a generic thing, here's it's
> > > the actual binary
> > >
> > > and maybe add "the bits can be found under include/uapi/linux/virtio*h,
> > > see macros such as VIRTIO_F_ and VIRTIO_NET_F_ for specific bit values"
> >
> > That's fine.
> >
> > >
> > > > +This is optional.
> > > > +
> > >
> > > and if not given what are the features?
> >
> > As in the past, determined by the parent/mgmt device, do we need to
> > document this?
>
> I think so, yes.

Ok.

>
> > >
> > > >  .BI mac " MACADDR"
> > > >  - specifies the mac address for the new vdpa device.
> > > >  This is applicable only for the network type of vdpa device. This is optional.
> > > > @@ -127,6 +132,11 @@ vdpa dev add name foo mgmtdev vdpa_sim_net
> > > >  Add the vdpa device named foo on the management device vdpa_sim_net.
> > > >  .RE
> > > >  .PP
> > > > +vdpa dev add name foo mgmtdev vdpa_sim_net device_features 0x300020000
> > > > +.RS 4
> > > > +Add the vdpa device named foo on the management device vdpa_sim_net with device_features of 0x300020000
> > > > +.RE
> > > > +.PP
> > > >  vdpa dev add name foo mgmtdev vdpa_sim_net mac 00:11:22:33:44:55
> > > >  .RS 4
> > > >  Add the vdpa device named foo on the management device vdpa_sim_net with mac address of 00:11:22:33:44:55.
> > > > diff --git a/vdpa/include/uapi/linux/vdpa.h b/vdpa/include/uapi/linux/vdpa.h
> > > > index 94e4dad1..7c961991 100644
> > > > --- a/vdpa/include/uapi/linux/vdpa.h
> > > > +++ b/vdpa/include/uapi/linux/vdpa.h
> > > > @@ -51,6 +51,7 @@ enum vdpa_attr {
> > > >       VDPA_ATTR_DEV_QUEUE_INDEX,              /* u32 */
> > > >       VDPA_ATTR_DEV_VENDOR_ATTR_NAME,         /* string */
> > > >       VDPA_ATTR_DEV_VENDOR_ATTR_VALUE,        /* u64 */
> > > > +     VDPA_ATTR_DEV_FEATURES,                 /* u64 */
> > > >
> > > >       /* new attributes must be added above here */
> > > >       VDPA_ATTR_MAX,
> > > > diff --git a/vdpa/vdpa.c b/vdpa/vdpa.c
> > > > index b73e40b4..9a866d61 100644
> > > > --- a/vdpa/vdpa.c
> > > > +++ b/vdpa/vdpa.c
> > > > @@ -27,6 +27,7 @@
> > > >  #define VDPA_OPT_VDEV_MTU            BIT(5)
> > > >  #define VDPA_OPT_MAX_VQP             BIT(6)
> > > >  #define VDPA_OPT_QUEUE_INDEX         BIT(7)
> > > > +#define VDPA_OPT_VDEV_FEATURES               BIT(8)
> > > >
> > > >  struct vdpa_opts {
> > > >       uint64_t present; /* flags of present items */
> > > > @@ -38,6 +39,7 @@ struct vdpa_opts {
> > > >       uint16_t mtu;
> > > >       uint16_t max_vqp;
> > > >       uint32_t queue_idx;
> > > > +     __u64 device_features;
> > > >  };
> > > >
> > > >  struct vdpa {
> > >
> > > why __u and not uint here?
> >
> > That's possible, will do.
> >
> > >
> > > > @@ -187,6 +189,17 @@ static int vdpa_argv_u32(struct vdpa *vdpa, int argc, char **argv,
> > > >       return get_u32(result, *argv, 10);
> > > >  }
> > > >
> > > > +static int vdpa_argv_u64_hex(struct vdpa *vdpa, int argc, char **argv,
> > > > +                          __u64 *result)
> > > > +{
> > > > +     if (argc <= 0 || !*argv) {
> > > > +             fprintf(stderr, "number expected\n");
> > > > +             return -EINVAL;
> > > > +     }
> > > > +
> > > > +     return get_u64(result, *argv, 16);
> > > > +}
> > > > +
> > > >  struct vdpa_args_metadata {
> > > >       uint64_t o_flag;
> > > >       const char *err_msg;
> > > > @@ -244,6 +257,10 @@ static void vdpa_opts_put(struct nlmsghdr *nlh, struct vdpa *vdpa)
> > > >               mnl_attr_put_u16(nlh, VDPA_ATTR_DEV_NET_CFG_MAX_VQP, opts->max_vqp);
> > > >       if (opts->present & VDPA_OPT_QUEUE_INDEX)
> > > >               mnl_attr_put_u32(nlh, VDPA_ATTR_DEV_QUEUE_INDEX, opts->queue_idx);
> > > > +     if (opts->present & VDPA_OPT_VDEV_FEATURES) {
> > > > +             mnl_attr_put_u64(nlh, VDPA_ATTR_DEV_FEATURES,
> > > > +                             opts->device_features);
> > > > +     }
> > > >  }
> > > >
> > > >  static int vdpa_argv_parse(struct vdpa *vdpa, int argc, char **argv,
> > > > @@ -329,6 +346,14 @@ static int vdpa_argv_parse(struct vdpa *vdpa, int argc, char **argv,
> > > >
> > > >                       NEXT_ARG_FWD();
> > > >                       o_found |= VDPA_OPT_QUEUE_INDEX;
> > > > +             } else if (!strcmp(*argv, "device_features") &&
> > > > +                        (o_optional & VDPA_OPT_VDEV_FEATURES)) {
> > > > +                     NEXT_ARG_FWD();
> > > > +                     err = vdpa_argv_u64_hex(vdpa, argc, argv,
> > > > +                                             &opts->device_features);
> > > > +                     if (err)
> > > > +                             return err;
> > > > +                     o_found |= VDPA_OPT_VDEV_FEATURES;
> > > >               } else {
> > > >                       fprintf(stderr, "Unknown option \"%s\"\n", *argv);
> > > >                       return -EINVAL;
> > >
> > >
> > > should not we validate the value we get? e.g. a mac feature
> > > requires that mac is supplied, etc.
> >
> > This isn't an "issue" that is introduced by this patch. Management
> > device is free to give _F_MAC even if the mac address is not
> > provisioned by the userspace. So this should be the responsibility of
> > the parent not the netlink/vdpa tool.
>
> right but now user can supply an invalid config. What validates it?

It should be the parent driver. Btw, we've already suffered from this:

root@10:~# vdpa dev add name foo mgmtdev vdpasim_net
root@10:~# vdpa dev config show foo
foo: mac 00:00:00:00:00:00 link up link_announce false mtu 1500
  negotiated_features MTU MAC CTRL_VQ CTRL_MAC_ADDR VERSION_1 ACCESS_PLATFORM

Fixing this in the userspace requires more work, e.g query the default
features from the mgmtdev. So I think we need to fix that separately.

>
> > > in fact hex isn't very user friendly. why not pass feature
> > > names instead?
> >
> > This can be added on top if necessary. In fact there's a plan to
> > accept JSON files for provisioning.
> >
> > The advantages of hex is we don't need to keep the name  synced with
> > the new features.
> >
> > Thanks
>
> right but it also means we can't interpret them in any way.

Probably, but we can start from this while adding a new interface on
top. (E.g it's similar to the way we currently used in
/sys/bus/vdpa/device/virtio0/features, the difference is that sysfs
uses bitmap).

Thanks

>
>
> > >
> > >
> > >
> > > > @@ -708,7 +733,7 @@ static int cmd_dev_add(struct vdpa *vdpa, int argc, char **argv)
> > > >       err = vdpa_argv_parse_put(nlh, vdpa, argc, argv,
> > > >                                 VDPA_OPT_VDEV_MGMTDEV_HANDLE | VDPA_OPT_VDEV_NAME,
> > > >                                 VDPA_OPT_VDEV_MAC | VDPA_OPT_VDEV_MTU |
> > > > -                               VDPA_OPT_MAX_VQP);
> > > > +                               VDPA_OPT_MAX_VQP | VDPA_OPT_VDEV_FEATURES);
> > > >       if (err)
> > > >               return err;
> > > >
> > > > --
> > > > 2.25.1
> > >
>

_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization



[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux