On Tue, Sep 1, 2026 at 9:10 PM Connor Kite <[email protected]> wrote: > > 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. >
Ok I see. Would it work if those details are encapsulated in a new struct, perhaps named SVQDeviceMemory, which all ShadowVirtQueue from a given device uses to allocate all memory together? It could use that explanation as a comment too. I'm very bad at naming things so feel free to rename it :). > 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. > That would be great, and the work on optimizing SVQ indirect descriptors could use it too.
