On Thu, Jan 29, 2026 at 3:00 AM Jason Wang <[email protected]> wrote: > > On Wed, Jan 28, 2026 at 8:45 PM Eugenio Pérez <[email protected]> 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 <[email protected]> > > --- > > 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!
