On Fri, Aug 28, 2026 at 5:16 AM Eugenio Perez Martin <[email protected]> wrote: > > On Tue, Aug 18, 2026 at 7:12 AM Connor Kite <[email protected]> wrote: > > > > By default svq vrings are placed in an anonymous memory map. As svqs > > will be leveraged to enable memory isolation in vhost-user, it is useful > > to be able to place the vrings in a shared isolation memory region. > > > > Adds the option to specify vring placement by providing a vring base > > address before starting the svq. > > > > Signed-off-by: Connor Kite <[email protected]> > > --- > > hw/virtio/vhost-shadow-virtqueue.c | 69 > > ++++++++++++++++++++++++++++++++------ > > hw/virtio/vhost-shadow-virtqueue.h | 8 ++++- > > 2 files changed, 66 insertions(+), 11 deletions(-) > > > > diff --git a/hw/virtio/vhost-shadow-virtqueue.c > > b/hw/virtio/vhost-shadow-virtqueue.c > > index 496e7e58a3..f54a61439a 100644 > > --- a/hw/virtio/vhost-shadow-virtqueue.c > > +++ b/hw/virtio/vhost-shadow-virtqueue.c > > @@ -812,6 +812,13 @@ size_t vhost_svq_device_area_size(const > > VhostShadowVirtqueue *svq) > > return ROUND_UP(used_size, qemu_real_host_page_size()); > > } > > > > +size_t vhost_svq_vring_total_size(VirtIODevice *vdev, VirtQueue *vq) > > +{ > > + VhostShadowVirtqueue svq; > > + svq.vring.num = virtio_queue_get_num(vdev, virtio_get_queue_index(vq)); > > + return vhost_svq_driver_area_size(&svq) + > > vhost_svq_device_area_size(&svq); > > +} > > + > > /** > > * Set a new file descriptor for the guest to kick the SVQ and notify for > > avail > > * > > @@ -842,6 +849,19 @@ void vhost_svq_set_svq_kick_fd(VhostShadowVirtqueue > > *svq, int svq_kick_fd) > > } > > } > > > > +/** > > + * Set vring base address if using fixed locations > > + * > > + * @svq: Shadow Virtqueue > > + * @addr: Points to new base address > > + */ > > + > > + void vhost_svq_set_base_addr(VhostShadowVirtqueue *svq, void *addr) > > + { > > + svq->base_addr = addr; > > + } > > + > > Would it work to keep that allocation detail in SVQ, instead of > letting it leak outside? Something like a flag to allocate the areas > with mmap or qemu_memfd_alloc, instead of the base_addr itself. >
For the purposes of the isolation mode as it currently stands, I'm not sure the allocation can be entirely hidden without adding significant complexity. The vrings need to be allocated in a region that gets sent to the vhost-user backend. If VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS isn't negotiated, then we are limited to 8 regions in total, so it is beneficial to be able to allocate them all in the same region, and in fact, the vrings are currently tacked onto the beginning of one of the bounce buffer regions so that they don't count against the limit. Having said that, a longer term desire would be to update the isolation region implementation such that it is no longer organized as a 1:1 copy of guest memory in terms of size and number of subregions. We would then need an allocator when copying guest buffers into the shared region, but it would be much less wasteful, and we could guarantee that only 1 region need be sent to the backend for the bounce buffers. At that point, the vrings could be mapped into their own region. There would need to be some mechanism to ensure they all get mapped into the same region, but I think those implementation details could be kept within SVQ. Thanks! Connor
