[v11] Add multiple address spaces support to VDUSE

[PATCH v11 12/12] vduse: bump version number

Posted by Eugenio Pérez 4 weeks, 1 day ago

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 <jasowang@redhat.com>
Reviewed-by: Xie Yongji <xieyongji@bytedance.com>
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
---
 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;
 	file->private_data = control;
 
 	return 0;
-- 
2.52.0

Re: [PATCH v11 12/12] vduse: bump version number

Posted by Jason Wang 3 weeks, 5 days ago

On Fri, Jan 9, 2026 at 11:25 PM Eugenio Pérez <eperezma@redhat.com> 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 <jasowang@redhat.com>
> Reviewed-by: Xie Yongji <xieyongji@bytedance.com>
> Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> ---
>  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

>         file->private_data = control;
>
>         return 0;
> --
> 2.52.0
>

Re: [PATCH v11 12/12] vduse: bump version number

Posted by Eugenio Perez Martin 3 weeks, 4 days ago

On Tue, Jan 13, 2026 at 7:25 AM Jason Wang <jasowang@redhat.com> wrote:
>
> On Fri, Jan 9, 2026 at 11:25 PM Eugenio Pérez <eperezma@redhat.com> 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 <jasowang@redhat.com>
> > Reviewed-by: Xie Yongji <xieyongji@bytedance.com>
> > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > ---
> >  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!