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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJaqyWdXqrFUYk_LSM=MNPSbRqt6O6J2=DPm=w3_Ex_m_3EawA@mail.gmail.com>
Date: Fri, 30 Jan 2026 09:12:06 +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 Fri, Jan 30, 2026 at 3:17 AM Jason Wang <jasowang@...hat.com> wrote:
>
> 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.
>

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.