[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJaqyWeMuGouepjgVg3Q1nyL04pjJMeVKa6kVZJ-sS_LBBXQXg@mail.gmail.com>
Date: Thu, 29 Jan 2026 09:07:23 +0100
From: Eugenio Perez Martin <eperezma@...hat.com>
To: Jason Wang <jasowang@...hat.com>
Cc: "Michael S . Tsirkin" <mst@...hat.com>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
Cindy Lu <lulu@...hat.com>, Laurent Vivier <lvivier@...hat.com>,
Stefano Garzarella <sgarzare@...hat.com>, linux-kernel@...r.kernel.org,
Maxime Coquelin <mcoqueli@...hat.com>, Yongji Xie <xieyongji@...edance.com>,
virtualization@...ts.linux.dev
Subject: Re: [PATCH 3/6] vduse: Add API v2 definition
On Thu, Jan 29, 2026 at 3:00 AM Jason Wang <jasowang@...hat.com> wrote:
>
> On Wed, Jan 28, 2026 at 8:45 PM Eugenio Pérez <eperezma@...hat.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@...hat.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!
Powered by blists - more mailing lists