On Tue, Jan 13, 2026 at 7:25 AM Jason Wang <[email protected]> wrote: > > On Fri, Jan 9, 2026 at 11:25 PM Eugenio Pérez <[email protected]> wrote: > > > > Finalize the series by advertising VDUSE API v1 support to userspace. > > > > Now that all required infrastructure for v1 (ASIDs, VQ groups, > > update_iotlb_v2) is in place, VDUSE devices can opt in to the new > > features. > > > > Acked-by: Jason Wang <[email protected]> > > Reviewed-by: Xie Yongji <[email protected]> > > Signed-off-by: Eugenio Pérez <[email protected]> > > --- > > drivers/vdpa/vdpa_user/vduse_dev.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c > > b/drivers/vdpa/vdpa_user/vduse_dev.c > > index 8227b5e9f3f6..5ad0ba1392f3 100644 > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > > @@ -2201,7 +2201,7 @@ static long vduse_ioctl(struct file *file, unsigned > > int cmd, > > break; > > > > ret = -EINVAL; > > - if (api_version > VDUSE_API_VERSION) > > + if (api_version > VDUSE_API_VERSION_1) > > break; > > > > ret = 0; > > @@ -2268,7 +2268,7 @@ static int vduse_open(struct inode *inode, struct > > file *file) > > if (!control) > > return -ENOMEM; > > > > - control->api_version = VDUSE_API_VERSION; > > + control->api_version = VDUSE_API_VERSION_1; > > This can break the "legacy" userspace that doesn't call VDUSE_SET_API_VERSION? > > Thanks >
It can result in a userland visible change, yes. Protecting it for the next version, thanks for pointing it out! I don't think you can "break" any valid userspace VDUSE actually, the only change the userland VDUSE can see is if calls VDUSE_IOTLB_GET_FD2, set the vq group in VDUSE_VQ_SETUP, set the asid in VDUSE_IOTLB_GET_INFO, or similar. In that case, the userland device gets -ENOIOCTLCMD or -EINVAL and suddenly something "valid" happens if the kernel applies this patch. But it is an userland visible change anyway, so I'll protect it for the next version. Thanks!
