From: Eugenio Perez Martin <eperezma@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
Cindy Lu <lulu@redhat.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
linux-kernel@vger.kernel.org,
Maxime Coquelin <mcoqueli@redhat.com>,
Stefano Garzarella <sgarzare@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
Yongji Xie <xieyongji@bytedance.com>,
virtualization@lists.linux.dev
Subject: Re: [PATCH v3 2/3] vduse: add VDUSE_GET_FEATURES ioctl
Date: Thu, 12 Mar 2026 08:11:58 +0100 [thread overview]
Message-ID: <CAJaqyWf3kgjQ5AQs3yYipNTDvGnF-arcXvJkAJP3G6+eoSB5aQ@mail.gmail.com> (raw)
In-Reply-To: <CACGkMEvafXSWZBsDtt5-zit5_po6U35ciP_-yhbv-MtKo4uG7Q@mail.gmail.com>
On Thu, Mar 12, 2026 at 4:56 AM Jason Wang <jasowang@redhat.com> wrote:
>
> On Wed, Mar 11, 2026 at 3:08 AM Eugenio Pérez <eperezma@redhat.com> wrote:
> >
> > Add an ioctl to allow VDUSE instances to query the available features
> > supported by the kernel module.
> >
> > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > ---
> > A simple u64 bitmap is used for feature flags. While a flexible array
> > could support indefinite expansion, 64 bits is sufficient for the
> > foreseeable future and simplifies the implementation.
> >
> > Also, dev_dbg is used for logging rather than dev_err as these can be
> > triggered from userspace.
> > ---
> > v3:
> > * Remove check for API_VERSION < 2
> > * Add comment about struct vduse_dev_config:vduse_features is only valid
> > if VDUSE_GET_FEATURES success.
> >
> > v2:
> > * return -EINVAL if ioctl called with version < 2, so userland visible
> > reply is kept (Jason).
> > ---
> > drivers/vdpa/vdpa_user/vduse_dev.c | 7 +++++++
> > include/uapi/linux/vduse.h | 7 ++++++-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> > index d1da7c15d98b..17e0358d3a68 100644
> > --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> > @@ -52,6 +52,9 @@
> >
> > #define IRQ_UNBOUND -1
> >
> > +/* Supported VDUSE features */
> > +static const uint64_t vduse_features;
> > +
> > /*
> > * VDUSE instance have not asked the vduse API version, so assume 0.
> > *
> > @@ -2207,6 +2210,10 @@ static long vduse_ioctl(struct file *file, unsigned int cmd,
> > ret = vduse_destroy_dev(name);
> > break;
> > }
> > + case VDUSE_GET_FEATURES:
> > + ret = put_user(vduse_features, (u64 __user *)argp);
> > + break;
> > +
> > default:
> > ret = -EINVAL;
> > break;
> > diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h
> > index 361eea511c21..e9b5f32a452d 100644
> > --- a/include/uapi/linux/vduse.h
> > +++ b/include/uapi/linux/vduse.h
> > @@ -33,6 +33,7 @@
> > * @vq_align: the allocation alignment of virtqueue's metadata
> > * @ngroups: number of vq groups that VDUSE device declares
> > * @nas: number of address spaces that VDUSE device declares
> > + * @vduse_features: VDUSE features
> > * @reserved: for future use, needs to be initialized to zero
> > * @config_size: the size of the configuration space
> > * @config: the buffer of the configuration space
> > @@ -49,7 +50,8 @@ struct vduse_dev_config {
> > __u32 vq_align;
> > __u32 ngroups; /* if VDUSE_API_VERSION >= 1 */
> > __u32 nas; /* if VDUSE_API_VERSION >= 1 */
> > - __u32 reserved[11];
> > + __u64 vduse_features; /* if VDUSE_GET_FEATURES is not EINVAL */
> > + __u32 reserved[9];
>
> If we go with VDUSE_GET_FEATURES, I'd perfer to go with
> VDUSE_SET_FEATURES intead of this.
>
I didn't realize the lack of symmetry, but that approach grows and
complicates the possible states of struct vduse_control and the
vduse_ioctl code for little benefit in my opinion. Making it atomic in
VDUSE_CREATE_DEV ioctl helps centralize all the potential errors.
Also, from previous experience with vhost_vdpa, the ioctls slow down
the device creation, which could affect things like VDUSE adoption for
containers etc.
On the other hand, it would make it easier to tell if the device
couldn't be created because of invalid features set. This is highly
unlikely, as the VDUSE device should retrieve the features by calling
VDUSE_GET_FEATURES earlier.
I don't think it is worth it, but if you think we should go that way
I'm ok with the change.
> But we can hear from others.
>
> > __u32 config_size;
> > __u8 config[];
> > };
> > @@ -63,6 +65,9 @@ struct vduse_dev_config {
> > */
> > #define VDUSE_DESTROY_DEV _IOW(VDUSE_BASE, 0x03, char[VDUSE_NAME_MAX])
> >
> > +/* Get the VDUSE supported features */
> > +#define VDUSE_GET_FEATURES _IOR(VDUSE_BASE, 0x04, __u64)
> > +
> > /* The ioctls for VDUSE device (/dev/vduse/$NAME) */
> >
> > /**
> > --
> > 2.53.0
> >
>
> Thanks
>
next prev parent reply other threads:[~2026-03-12 7:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 19:07 [PATCH v3 0/3] Add queue ready message to VDUSE Eugenio Pérez
2026-03-10 19:07 ` [PATCH v3 1/3] vduse: store control device pointer Eugenio Pérez
2026-03-10 19:07 ` [PATCH v3 2/3] vduse: add VDUSE_GET_FEATURES ioctl Eugenio Pérez
2026-03-12 3:55 ` Jason Wang
2026-03-12 7:11 ` Eugenio Perez Martin [this message]
2026-03-13 5:56 ` Jason Wang
2026-03-13 6:46 ` Eugenio Perez Martin
2026-03-10 19:07 ` [PATCH v3 3/3] vduse: add F_QUEUE_READY feature Eugenio Pérez
2026-03-12 3:58 ` Jason Wang
2026-03-12 6:24 ` Eugenio Perez Martin
2026-03-13 6:04 ` Jason Wang
2026-03-13 7:08 ` Eugenio Perez Martin
2026-03-24 14:01 ` Eugenio Perez Martin
2026-03-24 15:24 ` Michael S. Tsirkin
2026-03-26 2:44 ` Jason Wang
2026-03-26 6:56 ` Eugenio Perez Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJaqyWf3kgjQ5AQs3yYipNTDvGnF-arcXvJkAJP3G6+eoSB5aQ@mail.gmail.com \
--to=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=lvivier@redhat.com \
--cc=mcoqueli@redhat.com \
--cc=mst@redhat.com \
--cc=sgarzare@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xieyongji@bytedance.com \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox