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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACGkMEt9YODRPZqstZy8tdNuy66ofz33NfZizhYN-jQsjor4SQ@mail.gmail.com>
Date: Fri, 30 Jan 2026 10:17:00 +0800
From: Jason Wang <jasowang@...hat.com>
To: Eugenio Perez Martin <eperezma@...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 4:08 PM Eugenio Perez Martin
<eperezma@...hat.com> wrote:
>
> 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 :).

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

>