* [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).