Add queue ready message to VDUSE

[PATCH 3/6] vduse: Add API v2 definition

Posted by Eugenio Pérez 1 week, 2 days ago

Introduce the definition for VDUSE API V2.  This version serves as a
gateway for feature negotiation.

The kernel uses this version to determine if the userspace device
supports feature flags. Devices that do not explicitly negotiate API V2
will be blocked from querying available VDUSE features, ensuring
backward compatibility.

The next patches implement the new feature incrementally, only enabling
the VDUSE device to set the V2 API version by the end of the series.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
---
 include/uapi/linux/vduse.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h
index 68b4287f9fac..dea89ed281a7 100644
--- a/include/uapi/linux/vduse.h
+++ b/include/uapi/linux/vduse.h
@@ -14,6 +14,10 @@
 
 #define VDUSE_API_VERSION_1	1
 
+/* Features support */
+
+#define VDUSE_API_VERSION_2	2
+
 /*
  * Get the version of VDUSE API that kernel supported (VDUSE_API_VERSION).
  * This is used for future extension.
-- 
2.52.0

Re: [PATCH 3/6] vduse: Add API v2 definition

Posted by Jason Wang 1 week, 2 days ago

On Wed, Jan 28, 2026 at 8:45 PM Eugenio Pérez <eperezma@redhat.com> wrote:
>
> Introduce the definition for VDUSE API V2.  This version serves as a
> gateway for feature negotiation.
>
> The kernel uses this version to determine if the userspace device
> supports feature flags. Devices that do not explicitly negotiate API V2
> will be blocked from querying available VDUSE features, ensuring
> backward compatibility.
>
> The next patches implement the new feature incrementally, only enabling
> the VDUSE device to set the V2 API version by the end of the series.
>
> Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> ---
>  include/uapi/linux/vduse.h | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h
> index 68b4287f9fac..dea89ed281a7 100644
> --- a/include/uapi/linux/vduse.h
> +++ b/include/uapi/linux/vduse.h
> @@ -14,6 +14,10 @@
>
>  #define VDUSE_API_VERSION_1    1
>
> +/* Features support */
> +
> +#define VDUSE_API_VERSION_2    2

If we can catch the next release cycle, I would perfer not bumping
VDUSE version twice in the same release.

> +
>  /*
>   * Get the version of VDUSE API that kernel supported (VDUSE_API_VERSION).
>   * This is used for future extension.
> --
> 2.52.0
>

Thanks

Re: [PATCH 3/6] vduse: Add API v2 definition

Posted by Eugenio Perez Martin 1 week, 2 days ago

On Thu, Jan 29, 2026 at 3:00 AM Jason Wang <jasowang@redhat.com> wrote:
>
> On Wed, Jan 28, 2026 at 8:45 PM Eugenio Pérez <eperezma@redhat.com> wrote:
> >
> > Introduce the definition for VDUSE API V2.  This version serves as a
> > gateway for feature negotiation.
> >
> > The kernel uses this version to determine if the userspace device
> > supports feature flags. Devices that do not explicitly negotiate API V2
> > will be blocked from querying available VDUSE features, ensuring
> > backward compatibility.
> >
> > The next patches implement the new feature incrementally, only enabling
> > the VDUSE device to set the V2 API version by the end of the series.
> >
> > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > ---
> >  include/uapi/linux/vduse.h | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h
> > index 68b4287f9fac..dea89ed281a7 100644
> > --- a/include/uapi/linux/vduse.h
> > +++ b/include/uapi/linux/vduse.h
> > @@ -14,6 +14,10 @@
> >
> >  #define VDUSE_API_VERSION_1    1
> >
> > +/* Features support */
> > +
> > +#define VDUSE_API_VERSION_2    2
>
> If we can catch the next release cycle, I would perfer not bumping
> VDUSE version twice in the same release.
>

Following the number of versions that ASID required I don't expect
this one to be ready for the next release cycle :).

But if you ack the patches related with the vduse features handling,
MST is ok with that, and we're still in time to reach linux-next and
the next Linux, I can prepare a series where I add the features bits
to V1 API. Then, all ASID and VQ_ENABLE will be handled by feature
bits. Would that work for both of you?

If we're out of time, I'd prefer ASID to reach the next release cycle
as the series is already big.

Thanks!

Re: [PATCH 3/6] vduse: Add API v2 definition

Posted by Jason Wang 1 week, 1 day ago

On Thu, Jan 29, 2026 at 4:08 PM Eugenio Perez Martin
<eperezma@redhat.com> wrote:
>
> On Thu, Jan 29, 2026 at 3:00 AM Jason Wang <jasowang@redhat.com> wrote:
> >
> > On Wed, Jan 28, 2026 at 8:45 PM Eugenio Pérez <eperezma@redhat.com> wrote:
> > >
> > > Introduce the definition for VDUSE API V2.  This version serves as a
> > > gateway for feature negotiation.
> > >
> > > The kernel uses this version to determine if the userspace device
> > > supports feature flags. Devices that do not explicitly negotiate API V2
> > > will be blocked from querying available VDUSE features, ensuring
> > > backward compatibility.
> > >
> > > The next patches implement the new feature incrementally, only enabling
> > > the VDUSE device to set the V2 API version by the end of the series.
> > >
> > > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > > ---
> > >  include/uapi/linux/vduse.h | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h
> > > index 68b4287f9fac..dea89ed281a7 100644
> > > --- a/include/uapi/linux/vduse.h
> > > +++ b/include/uapi/linux/vduse.h
> > > @@ -14,6 +14,10 @@
> > >
> > >  #define VDUSE_API_VERSION_1    1
> > >
> > > +/* Features support */
> > > +
> > > +#define VDUSE_API_VERSION_2    2
> >
> > If we can catch the next release cycle, I would perfer not bumping
> > VDUSE version twice in the same release.
> >
>
> Following the number of versions that ASID required I don't expect
> this one to be ready for the next release cycle :).

Then it's probably fine.

>
> But if you ack the patches related with the vduse features handling,
> MST is ok with that, and we're still in time to reach linux-next and
> the next Linux, I can prepare a series where I add the features bits
> to V1 API. Then, all ASID and VQ_ENABLE will be handled by feature
> bits. Would that work for both of you?

Maybe you can start with V1 and if we can't catch this release, a
respin will be needed anyhow.

>
> If we're out of time, I'd prefer ASID to reach the next release cycle
> as the series is already big.
>
> Thanks!

Thanks

>

Re: [PATCH 3/6] vduse: Add API v2 definition

Posted by Eugenio Perez Martin 1 week, 1 day ago

On Fri, Jan 30, 2026 at 3:17 AM Jason Wang <jasowang@redhat.com> wrote:
>
> On Thu, Jan 29, 2026 at 4:08 PM Eugenio Perez Martin
> <eperezma@redhat.com> wrote:
> >
> > On Thu, Jan 29, 2026 at 3:00 AM Jason Wang <jasowang@redhat.com> wrote:
> > >
> > > On Wed, Jan 28, 2026 at 8:45 PM Eugenio Pérez <eperezma@redhat.com> wrote:
> > > >
> > > > Introduce the definition for VDUSE API V2.  This version serves as a
> > > > gateway for feature negotiation.
> > > >
> > > > The kernel uses this version to determine if the userspace device
> > > > supports feature flags. Devices that do not explicitly negotiate API V2
> > > > will be blocked from querying available VDUSE features, ensuring
> > > > backward compatibility.
> > > >
> > > > The next patches implement the new feature incrementally, only enabling
> > > > the VDUSE device to set the V2 API version by the end of the series.
> > > >
> > > > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > > > ---
> > > >  include/uapi/linux/vduse.h | 4 ++++
> > > >  1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h
> > > > index 68b4287f9fac..dea89ed281a7 100644
> > > > --- a/include/uapi/linux/vduse.h
> > > > +++ b/include/uapi/linux/vduse.h
> > > > @@ -14,6 +14,10 @@
> > > >
> > > >  #define VDUSE_API_VERSION_1    1
> > > >
> > > > +/* Features support */
> > > > +
> > > > +#define VDUSE_API_VERSION_2    2
> > >
> > > If we can catch the next release cycle, I would perfer not bumping
> > > VDUSE version twice in the same release.
> > >
> >
> > Following the number of versions that ASID required I don't expect
> > this one to be ready for the next release cycle :).
>
> Then it's probably fine.
>
> >
> > But if you ack the patches related with the vduse features handling,
> > MST is ok with that, and we're still in time to reach linux-next and
> > the next Linux, I can prepare a series where I add the features bits
> > to V1 API. Then, all ASID and VQ_ENABLE will be handled by feature
> > bits. Would that work for both of you?
>
> Maybe you can start with V1 and if we can't catch this release, a
> respin will be needed anyhow.
>

I'm fine with that if you ask it, but if it gets merged (unlikely)
we'll have a few commits with V1 that supports the VDUSE_GET_FEATURES
and others that do not.