From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Eugenio Perez Martin <eperezma@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
linux-kernel@vger.kernel.org,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
Maxime Coquelin <mcoqueli@redhat.com>, Cindy Lu <lulu@redhat.com>,
virtualization@lists.linux.dev,
Yongji Xie <xieyongji@bytedance.com>,
Stefano Garzarella <sgarzare@redhat.com>
Subject: Re: [PATCH v14 11/13] vduse: add vq group asid support
Date: Mon, 19 Jan 2026 04:39:17 -0500 [thread overview]
Message-ID: <20260119043804-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CACGkMEtyyPJQ3t_ckwZyNRHW2_fqm=09DEe-__Rvz0pQoUqtsQ@mail.gmail.com>
On Mon, Jan 19, 2026 at 04:34:11PM +0800, Jason Wang wrote:
> On Mon, Jan 19, 2026 at 4:10 PM Eugenio Perez Martin
> <eperezma@redhat.com> wrote:
> >
> > On Mon, Jan 19, 2026 at 8:17 AM Jason Wang <jasowang@redhat.com> wrote:
> > >
> > > On Fri, Jan 16, 2026 at 10:05 PM Eugenio Pérez <eperezma@redhat.com> wrote:
> > > >
> > > > Add support for assigning Address Space Identifiers (ASIDs) to each VQ
> > > > group. This enables mapping each group into a distinct memory space.
> > > >
> > > > The vq group to ASID association is protected by a rwlock now. But the
> > > > mutex domain_lock keeps protecting the domains of all ASIDs, as some
> > > > operations like the one related with the bounce buffer size still
> > > > requires to lock all the ASIDs.
> > > >
> > > > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > > >
> > > > ---
> > > > Future improvements can include performance optimizations on top like
> > > > ore to RCU or thread synchronized atomics, or hardening by tracking ASID
> > > > or ASID hashes on unused bits of the DMA address.
> > > >
> > > > Tested virtio_vdpa by adding manually two threads in vduse_set_status:
> > > > one of them modifies the vq group 0 ASID and the other one map and unmap
> > > > memory continuously. After a while, the two threads stop and the usual
> > > > work continues. Test with version 0, version 1 with the old ioctl, and
> > > > version 1 with the new ioctl.
> > > >
> > > > Tested with vhost_vdpa by migrating a VM while ping on OVS+VDUSE. A few
> > > > workaround were needed in some parts:
> > > > * Do not enable CVQ before data vqs in QEMU, as VDUSE does not forward
> > > > the enable message to the userland device. This will be solved in the
> > > > future.
> > > > * Share the suspended state between all vhost devices in QEMU:
> > > > https://lists.nongnu.org/archive/html/qemu-devel/2025-11/msg02947.html
> > > > * Implement a fake VDUSE suspend vdpa operation callback that always
> > > > returns true in the kernel. DPDK suspend the device at the first
> > > > GET_VRING_BASE.
> > > > * Remove the CVQ blocker in ASID.
> > > >
> > > > The driver vhost_vdpa was also tested with version 0, version 1 with the
> > > > old ioctl, version 1 with the new ioctl but only one ASID, and version 1
> > > > with many ASID.
> > > >
> > >
> > > Looks good overall, but I spot a small issue:
> > >
> > > int vduse_domain_add_user_bounce_pages(struct vduse_iova_domain *domain,
> > > struct page **pages, int count)
> > > {
> > > struct vduse_bounce_map *map, *head_map;
> > > ...
> > >
> > > /* Now we don't support partial mapping */
> > > if (count != (domain->bounce_size >> PAGE_SHIFT))
> > > return -EINVAL;
> > >
> > > Here we still use domain->bounce_size even if we support multiple as,
> > > this conflicts with the case without userspace memory.
> > >
> >
> > I don't follow you. My understanding from the previous discussion is
> > that the bounce size is distributed evenly per AS. Should we just have
> > a global bounce buffer size and protect that the amount of added
> > memory of all domains is less than that bounce size?
>
> I meant we require bounce_size / nas to be the size of the bounce
> buffer size of each AS.
>
> But for userspace registered memory, it requires bounce_size per AS.
>
> Thanks
I don't really understand what you are saying here, either.
Could you explain what your suggestion is?
> >
next prev parent reply other threads:[~2026-01-19 9:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 14:04 [PATCH v14 00/13] Add multiple address spaces support to VDUSE Eugenio Pérez
2026-01-16 14:04 ` [PATCH v14 01/13] vhost: move vdpa group bound check to vhost_vdpa Eugenio Pérez
2026-01-19 6:29 ` Jason Wang
2026-01-16 14:04 ` [PATCH v14 02/13] vduse: add v1 API definition Eugenio Pérez
2026-01-16 14:04 ` [PATCH v14 03/13] vduse: add vq group support Eugenio Pérez
2026-01-16 14:04 ` [PATCH v14 04/13] vduse: return internal vq group struct as map token Eugenio Pérez
2026-01-16 14:04 ` [PATCH v14 05/13] vdpa: document set_group_asid thread safety Eugenio Pérez
2026-01-19 6:30 ` Jason Wang
2026-01-16 14:04 ` [PATCH v14 06/13] vhost: forbid change vq groups ASID if DRIVER_OK is set Eugenio Pérez
2026-01-19 6:30 ` Jason Wang
2026-01-16 14:04 ` [PATCH v14 07/13] vduse: refactor vdpa_dev_add for goto err handling Eugenio Pérez
2026-01-16 14:04 ` [PATCH v14 08/13] vduse: remove unused vaddr parameter of vduse_domain_free_coherent Eugenio Pérez
2026-01-16 14:04 ` [PATCH v14 09/13] vduse: take out allocations from vduse_dev_alloc_coherent Eugenio Pérez
2026-01-19 6:42 ` Jason Wang
2026-01-16 14:04 ` [PATCH v14 10/13] vduse: merge tree search logic of IOTLB_GET_FD and IOTLB_GET_INFO ioctls Eugenio Pérez
2026-01-16 14:04 ` [PATCH v14 11/13] vduse: add vq group asid support Eugenio Pérez
2026-01-16 18:48 ` ALOK TIWARI
2026-01-19 7:16 ` Jason Wang
2026-01-19 8:09 ` Eugenio Perez Martin
2026-01-19 8:34 ` Jason Wang
2026-01-19 9:39 ` Michael S. Tsirkin [this message]
2026-01-19 10:29 ` Eugenio Perez Martin
2026-01-19 12:25 ` Jason Wang
2026-01-16 14:04 ` [PATCH v14 12/13] vduse: bump version number Eugenio Pérez
2026-01-16 14:04 ` [PATCH v14 13/13] Documentation: Add documentation for VDUSE Address Space IDs Eugenio Pérez
2026-01-16 18:41 ` ALOK TIWARI
2026-01-19 7:23 ` Eugenio Perez Martin
2026-01-19 7:19 ` Jason Wang
2026-01-19 7:40 ` Eugenio Perez Martin
2026-01-19 12:27 ` Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260119043804-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=lvivier@redhat.com \
--cc=mcoqueli@redhat.com \
--cc=sgarzare@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xieyongji@bytedance.com \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox