public inbox for virtualization@lists.linux-foundation.org
 help / color / mirror / Atom feed
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>, Laurent Vivier <lvivier@redhat.com>,
	 Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
	Maxime Coquelin <mcoqueli@redhat.com>,
	 linux-kernel@vger.kernel.org,
	Yongji Xie <xieyongji@bytedance.com>,
	 Stefano Garzarella <sgarzare@redhat.com>,
	virtualization@lists.linux.dev
Subject: Re: [PATCH v2 3/5] vduse: add VDUSE_GET_FEATURES ioctl
Date: Fri, 13 Feb 2026 08:39:02 +0100	[thread overview]
Message-ID: <CAJaqyWe4V77K7R+d_HvSR_2j+sXqemr+zcLUOf7BPu1hT1-ztA@mail.gmail.com> (raw)
In-Reply-To: <CACGkMEuY0f1xjxc4n6QzKfUa-LFrM-X_xtOpTwm5SWjfVvikHA@mail.gmail.com>

On Fri, Feb 13, 2026 at 2:25 AM Jason Wang <jasowang@redhat.com> wrote:
>
> On Thu, Feb 12, 2026 at 4:23 PM Eugenio Perez Martin
> <eperezma@redhat.com> wrote:
> >
> > On Thu, Feb 12, 2026 at 9:07 AM Jason Wang <jasowang@redhat.com> wrote:
> > >
> > > On Tue, Feb 10, 2026 at 4:26 PM 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.
> > > > ---
> > > > v2:
> > > > * return -EINVAL if ioctl called with version < 2, so userland visible
> > > >   reply is kept (Jason).
> > > > ---
> > > >  drivers/vdpa/vdpa_user/vduse_dev.c | 28 ++++++++++++++++++++++++++++
> > > >  include/uapi/linux/vduse.h         |  7 ++++++-
> > > >  2 files changed, 34 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > index d1da7c15d98b..7458cbaed4c7 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.
> > > >   *
> > > > @@ -1947,6 +1950,19 @@ static bool vduse_validate_config(struct vduse_dev_config *config,
> > > >                          sizeof(config->reserved)))
> > > >                 return false;
> > > >
> > > > +       if (api_version < VDUSE_API_VERSION_2) {
> > > > +               if (config->vduse_features) {
> > > > +                       dev_dbg(vduse_ctrl_dev,
> > > > +                               "config->vduse_features with version %llu",
> > > > +                               api_version);
> > > > +                       return false;
> > > > +               }
> > > > +       } else {
> > > > +               if (config->vduse_features & ~vduse_features)
> > > > +                       return false;
> > > > +       }
> > > > +
> > > > +
> > > >         if (api_version < VDUSE_API_VERSION_1 &&
> > > >             (config->ngroups || config->nas))
> > > >                 return false;
> > > > @@ -2207,6 +2223,18 @@ static long vduse_ioctl(struct file *file, unsigned int cmd,
> > > >                 ret = vduse_destroy_dev(name);
> > > >                 break;
> > > >         }
> > > > +       case VDUSE_GET_FEATURES:
> > > > +               if (control->api_version < VDUSE_API_VERSION_2) {
> > > > +                       dev_dbg(vduse_ctrl_dev,
> > > > +                               "VDUSE_GET_FEATURES ioctl with version %llu",
> > > > +                               control->api_version);
> > > > +                       ret = -EINVAL;
> > > > +                       break;
> > > > +               }
> > > > +
> > > > +               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 27832d46084c..8898d9daa777 100644
> > > > --- a/include/uapi/linux/vduse.h
> > > > +++ b/include/uapi/linux/vduse.h
> > > > @@ -37,6 +37,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
> > > > @@ -53,7 +54,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;
> > >
> > > Nit: Should we document " /* if VDUSE_API_VERSION >= 2 */
> > >
> > > But I have an open question, is this better to just introduce a
> > > VDUSE_SET_FEATURES then we can do negotiation to avoid bumping API
> > > versions?
> > >
> >
> > How do you know if you can call VDUSE_GET_FEATURES and
> > VDUSE_SET_FEATURES then? vduse_ioctl does not even return -ENOIOCMD
> > but -EINVAL if you call the equivalent of VDUSE_GET_FEATURES on
> > current Linux master. Or should the VDUSE instance assume that if the
> > ioctl returns -EINVAL the kernel does not support them?
>
> If we go that way, yes.
>

I'm ok with doing the change. Kind of, I still think that increasing
the API version is way cleaner, so no ioctl returns any error in
regular initialization. But python's style "ask forgiveness not
permission" is also ok for me.

But I'm really missing the motivation of it. What's the problem with
the increase of the version that you are trying to solve here?

Can we make a rule to know when to increase the version, and when it
is not needed and it is ok for ioctls to just return -EINVAL or
-ENOIOCTLCMD, so future series can hit the right behavior from earlier
versions?

From your comment I extract that we don't need to increase the API
version number if we just add ioctls commands to the device, like
probing if an ioctl exists. Also, we don't need to increase the
version if we can tell if a member in vduse_dev_config is known to
exist because a previous ioctl (or feature flag) succeeded.

Am I missing something?


  reply	other threads:[~2026-02-13  7:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-10  8:25 [PATCH v2 0/5] Add queue ready message to VDUSE Eugenio Pérez
2026-02-10  8:25 ` [PATCH v2 1/5] vduse: store control device pointer Eugenio Pérez
2026-02-10  8:25 ` [PATCH v2 2/5] vduse: Add API v2 definition Eugenio Pérez
2026-02-10  8:25 ` [PATCH v2 3/5] vduse: add VDUSE_GET_FEATURES ioctl Eugenio Pérez
2026-02-12  8:06   ` Jason Wang
2026-02-12  8:22     ` Eugenio Perez Martin
2026-02-13  1:25       ` Jason Wang
2026-02-13  7:39         ` Eugenio Perez Martin [this message]
2026-03-03  7:20           ` Jason Wang
2026-03-03  7:33             ` Michael S. Tsirkin
2026-03-03  9:39             ` Eugenio Perez Martin
2026-02-12  9:04     ` Eugenio Perez Martin
2026-02-10  8:25 ` [PATCH v2 4/5] vduse: advertise API V2 support Eugenio Pérez
2026-02-10  8:25 ` [PATCH v2 5/5] vduse: add F_QUEUE_READY feature Eugenio Pérez

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=CAJaqyWe4V77K7R+d_HvSR_2j+sXqemr+zcLUOf7BPu1hT1-ztA@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