* [PATCH] vdpa: allow provisioning device features
@ 2022-11-10 7:58 Jason Wang
2022-11-10 11:00 ` Michael S. Tsirkin
0 siblings, 1 reply; 5+ messages in thread
From: Jason Wang @ 2022-11-10 7:58 UTC (permalink / raw)
To: dsahern, netdev; +Cc: mst, virtualization, eperezma, elic
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@redhat.com>
---
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"
+- specifies the device features that is provisioned for the new vdpa device.
+This is optional.
+
.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 {
@@ -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;
@@ -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@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH] vdpa: allow provisioning device features 2022-11-10 7:58 [PATCH] vdpa: allow provisioning device features Jason Wang @ 2022-11-10 11:00 ` Michael S. Tsirkin 2022-11-11 7:17 ` Jason Wang 0 siblings, 1 reply; 5+ messages in thread From: Michael S. Tsirkin @ 2022-11-10 11:00 UTC (permalink / raw) To: Jason Wang; +Cc: netdev, dsahern, virtualization, eperezma, elic 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@redhat.com> > --- > 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 > +- 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" > +This is optional. > + and if not given what are the features? > .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? > @@ -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. in fact hex isn't very user friendly. why not pass feature names instead? > @@ -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@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] vdpa: allow provisioning device features 2022-11-10 11:00 ` Michael S. Tsirkin @ 2022-11-11 7:17 ` Jason Wang 2022-11-11 10:19 ` Michael S. Tsirkin 0 siblings, 1 reply; 5+ messages in thread From: Jason Wang @ 2022-11-11 7:17 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: netdev, dsahern, virtualization, eperezma, elic On Thu, Nov 10, 2022 at 7:01 PM Michael S. Tsirkin <mst@redhat.com> 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@redhat.com> > > --- > > 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? > > > .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. > 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 > > > > > @@ -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@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] vdpa: allow provisioning device features 2022-11-11 7:17 ` Jason Wang @ 2022-11-11 10:19 ` Michael S. Tsirkin 2022-11-15 6:36 ` Jason Wang 0 siblings, 1 reply; 5+ messages in thread From: Michael S. Tsirkin @ 2022-11-11 10:19 UTC (permalink / raw) To: Jason Wang; +Cc: netdev, dsahern, virtualization, eperezma, elic 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@redhat.com> 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@redhat.com> > > > --- > > > 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. > > > > > .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? > > 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. > > > > > > > > > @@ -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@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] vdpa: allow provisioning device features 2022-11-11 10:19 ` Michael S. Tsirkin @ 2022-11-15 6:36 ` Jason Wang 0 siblings, 0 replies; 5+ messages in thread From: Jason Wang @ 2022-11-15 6:36 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: netdev, dsahern, virtualization, eperezma, elic On Fri, Nov 11, 2022 at 6:19 PM Michael S. Tsirkin <mst@redhat.com> 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@redhat.com> 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@redhat.com> > > > > --- > > > > 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@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-11-15 6:37 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-11-10 7:58 [PATCH] vdpa: allow provisioning device features Jason Wang 2022-11-10 11:00 ` Michael S. Tsirkin 2022-11-11 7:17 ` Jason Wang 2022-11-11 10:19 ` Michael S. Tsirkin 2022-11-15 6:36 ` Jason Wang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).