From: Stefan Hajnoczi <stefanha@redhat.com>
To: Albert Esteve <aesteve@redhat.com>
Cc: qemu-devel@nongnu.org, david@redhat.com,
"Michael S. Tsirkin" <mst@redhat.com>,
hi@alyssa.is, jasowang@redhat.com,
"Laurent Vivier" <lvivier@redhat.com>,
dbassey@redhat.com, "Stefano Garzarella" <sgarzare@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
stevensd@chromium.org, "Fabiano Rosas" <farosas@suse.de>,
"Alex Bennée" <alex.bennee@linaro.org>,
slp@redhat.com
Subject: Re: [PATCH v7 8/8] vhost-user-device: Add shared memory BAR
Date: Tue, 19 Aug 2025 06:42:34 -0400 [thread overview]
Message-ID: <20250819104234.GB30271@fedora> (raw)
In-Reply-To: <20250818100353.1560655-9-aesteve@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 8503 bytes --]
On Mon, Aug 18, 2025 at 12:03:53PM +0200, Albert Esteve wrote:
> Add shared memory BAR support to vhost-user-device-pci
> to enable direct file mapping for VIRTIO Shared
> Memory Regions.
>
> The implementation creates a consolidated shared
> memory BAR that contains all VIRTIO Shared
> Memory Regions as subregions. Each region is
> configured with its proper shmid, size, and
> offset within the BAR. The number and size of
> regions are retrieved via VHOST_USER_GET_SHMEM_CONFIG
> message sent by vhost-user-base during realization
> after virtio_init().
>
> Specifiically, it uses BAR 3 to avoid conflicts, as
> it is currently unused.
>
> The shared memory BAR is only created when the
> backend supports VHOST_USER_PROTOCOL_F_SHMEM and
> has configured shared memory regions. This maintains
> backward compatibility with backends that do not
> support shared memory functionality.
>
> Signed-off-by: Albert Esteve <aesteve@redhat.com>
> ---
> hw/virtio/vhost-user-base.c | 49 +++++++++++++++++++++++++++++--
> hw/virtio/vhost-user-device-pci.c | 34 +++++++++++++++++++--
> 2 files changed, 78 insertions(+), 5 deletions(-)
>
> diff --git a/hw/virtio/vhost-user-base.c b/hw/virtio/vhost-user-base.c
> index ff67a020b4..932f9b5596 100644
> --- a/hw/virtio/vhost-user-base.c
> +++ b/hw/virtio/vhost-user-base.c
> @@ -16,6 +16,7 @@
> #include "hw/virtio/virtio-bus.h"
> #include "hw/virtio/vhost-user-base.h"
> #include "qemu/error-report.h"
> +#include "migration/blocker.h"
>
> static void vub_start(VirtIODevice *vdev)
> {
> @@ -276,7 +277,9 @@ static void vub_device_realize(DeviceState *dev, Error **errp)
> {
> VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> VHostUserBase *vub = VHOST_USER_BASE(dev);
> - int ret;
> + uint64_t memory_sizes[VIRTIO_MAX_SHMEM_REGIONS];
> + g_autofree char *name = NULL;
> + int i, ret, nregions;
>
> if (!vub->chardev.chr) {
> error_setg(errp, "vhost-user-base: missing chardev");
> @@ -319,7 +322,7 @@ static void vub_device_realize(DeviceState *dev, Error **errp)
>
> /* Allocate queues */
> vub->vqs = g_ptr_array_sized_new(vub->num_vqs);
> - for (int i = 0; i < vub->num_vqs; i++) {
> + for (i = 0; i < vub->num_vqs; i++) {
> g_ptr_array_add(vub->vqs,
> virtio_add_queue(vdev, vub->vq_size,
> vub_handle_output));
> @@ -333,11 +336,51 @@ static void vub_device_realize(DeviceState *dev, Error **errp)
> VHOST_BACKEND_TYPE_USER, 0, errp);
>
> if (ret < 0) {
> - do_vhost_user_cleanup(vdev, vub);
> + goto err;
> + }
> +
> + ret = vub->vhost_dev.vhost_ops->vhost_get_shmem_config(&vub->vhost_dev,
> + &nregions,
> + memory_sizes,
> + errp);
> +
> + if (ret < 0) {
> + goto err;
> + }
> +
> + for (i = 0; i < nregions; i++) {
> + if (memory_sizes[i]) {
> + if (vub->vhost_dev.migration_blocker == NULL) {
> + error_setg(&vub->vhost_dev.migration_blocker,
> + "Migration disabled: devices with VIRTIO Shared Memory "
> + "Regions do not support migration yet.");
> + ret = migrate_add_blocker_normal(
> + &vub->vhost_dev.migration_blocker,
> + errp);
> +
> + if (ret < 0) {
> + goto err;
> + }
> + }
> +
> + if (memory_sizes[i] % qemu_real_host_page_size() != 0) {
> + error_setg(errp, "Shared memory %d size must be a power of 2 "
> + "no smaller than the page size", i);
> + goto err;
> + }
> +
> + name = g_strdup_printf("vub-shm-%d", i);
name is leaked because it's scope extends until the end of the function
(after the loop) but a newly allocated string is assigned each time
around the loop. This can be fixed by moving the local variable
declaration inside the if statement body.
> + memory_region_init(&virtio_new_shmem_region(vdev, i)->mr,
> + OBJECT(vdev), name,
> + memory_sizes[i]);
->mr is already initialized inside virtio_new_shmem_region(). I suggest
changing the definition of virtio_new_shmem_region() like this:
void virtio_add_shmem_region(VirtIODevice *vdev, uint8_t shmid,
uint64_t size)
and then calling it like this:
virtio_add_shmem_region(vdev, shmid, memory_sizes[i]);
("new" usually returns a new instance whereas "add" modifies an owner
object/container. I think "add" is more appropriate here.)
> + }
> }
>
> qemu_chr_fe_set_handlers(&vub->chardev, NULL, NULL, vub_event, NULL,
> dev, NULL, true);
> + return;
> +err:
> + do_vhost_user_cleanup(vdev, vub);
> }
>
> static void vub_device_unrealize(DeviceState *dev)
> diff --git a/hw/virtio/vhost-user-device-pci.c b/hw/virtio/vhost-user-device-pci.c
> index f10bac874e..bac99e7c60 100644
> --- a/hw/virtio/vhost-user-device-pci.c
> +++ b/hw/virtio/vhost-user-device-pci.c
> @@ -8,14 +8,18 @@
> */
>
> #include "qemu/osdep.h"
> +#include "qapi/error.h"
> #include "hw/qdev-properties.h"
> #include "hw/virtio/vhost-user-base.h"
> #include "hw/virtio/virtio-pci.h"
>
> +#define VIRTIO_DEVICE_PCI_SHMEM_BAR 3
> +
> struct VHostUserDevicePCI {
> VirtIOPCIProxy parent_obj;
>
> VHostUserBase vub;
> + MemoryRegion shmembar;
> };
>
> #define TYPE_VHOST_USER_DEVICE_PCI "vhost-user-device-pci-base"
> @@ -25,10 +29,36 @@ OBJECT_DECLARE_SIMPLE_TYPE(VHostUserDevicePCI, VHOST_USER_DEVICE_PCI)
> static void vhost_user_device_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
> {
> VHostUserDevicePCI *dev = VHOST_USER_DEVICE_PCI(vpci_dev);
> - DeviceState *vdev = DEVICE(&dev->vub);
> + DeviceState *dev_state = DEVICE(&dev->vub);
> + VirtIODevice *vdev = VIRTIO_DEVICE(dev_state);
> + VirtioSharedMemory *shmem, *next;
> + uint64_t offset = 0, shmem_size = 0;
>
> vpci_dev->nvectors = 1;
> - qdev_realize(vdev, BUS(&vpci_dev->bus), errp);
> + qdev_realize(dev_state, BUS(&vpci_dev->bus), errp);
> +
> + QSIMPLEQ_FOREACH_SAFE(shmem, &vdev->shmem_list, entry, next) {
This is not specific to vhost-user-device-pci.c. All VIRTIO devices with
Shared Memory Regions need PCI BAR setup code. Since vdev->shmem_list is
part of the core hw/virtio/ code, it would make sense to move this into
into hw/virtio/virtio-pci.c.
> + if (shmem->mr.size > UINT64_MAX - shmem_size) {
> + error_setg(errp, "Total shared memory required overflow");
> + return;
> + }
> + shmem_size = shmem_size + shmem->mr.size;
> + }
> + if (shmem_size) {
> + memory_region_init(&dev->shmembar, OBJECT(vpci_dev),
> + "vhost-device-pci-shmembar", shmem_size);
> + QSIMPLEQ_FOREACH_SAFE(shmem, &vdev->shmem_list, entry, next) {
> + memory_region_add_subregion(&dev->shmembar, offset, &shmem->mr);
> + virtio_pci_add_shm_cap(vpci_dev, VIRTIO_DEVICE_PCI_SHMEM_BAR,
> + offset, shmem->mr.size, shmem->shmid);
> + offset = offset + shmem->mr.size;
> + }
> + pci_register_bar(&vpci_dev->pci_dev, VIRTIO_DEVICE_PCI_SHMEM_BAR,
> + PCI_BASE_ADDRESS_SPACE_MEMORY |
> + PCI_BASE_ADDRESS_MEM_PREFETCH |
> + PCI_BASE_ADDRESS_MEM_TYPE_64,
> + &dev->shmembar);
This does not follow the same approach as virtio-gpu-pci.c and
virtio-vga.c. They config the VirtIOPCIProxy's BARs
(->modern_io_bar_idx, ->modern_mem_bar_idx, and ->msix_bar_idx) to
control the BAR layout first and then call qdev_realize().
Why does this patch do things differently? It looks like it's assuming
vpci_dev always has a specific BAR layout (it could change).
> + }
> }
>
> static void vhost_user_device_pci_class_init(ObjectClass *klass,
> --
> 2.49.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2025-08-19 10:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 10:03 [PATCH v7 0/8] vhost-user: Add SHMEM_MAP/UNMAP requests Albert Esteve
2025-08-18 10:03 ` [PATCH v7 1/8] vhost-user: Add VirtIO Shared Memory map request Albert Esteve
2025-08-18 18:58 ` Stefan Hajnoczi
2025-08-19 12:47 ` Albert Esteve
2025-08-19 12:56 ` Albert Esteve
2025-08-19 9:22 ` David Hildenbrand
2025-08-18 10:03 ` [PATCH v7 2/8] vhost_user.rst: Align VhostUserMsg excerpt members Albert Esteve
2025-08-18 10:03 ` [PATCH v7 3/8] vhost_user.rst: Add SHMEM_MAP/_UNMAP to spec Albert Esteve
2025-08-18 10:03 ` [PATCH v7 4/8] vhost_user: Add frontend get_shmem_config command Albert Esteve
2025-08-18 10:03 ` [PATCH v7 5/8] vhost_user.rst: Add GET_SHMEM_CONFIG message Albert Esteve
2025-08-18 10:03 ` [PATCH v7 6/8] tests/qtest: Add GET_SHMEM validation test Albert Esteve
2025-08-18 23:14 ` Stefan Hajnoczi
2025-08-19 12:16 ` Albert Esteve
2025-08-20 8:47 ` Alyssa Ross
2025-08-20 15:42 ` Stefan Hajnoczi
2025-08-20 20:33 ` Stefan Hajnoczi
2025-08-21 6:50 ` Albert Esteve
2025-09-10 11:10 ` Albert Esteve
2025-08-18 10:03 ` [PATCH v7 7/8] qmp: add shmem feature map Albert Esteve
2025-08-18 10:03 ` [PATCH v7 8/8] vhost-user-device: Add shared memory BAR Albert Esteve
2025-08-19 10:42 ` Stefan Hajnoczi [this message]
2025-08-19 11:41 ` Albert Esteve
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=20250819104234.GB30271@fedora \
--to=stefanha@redhat.com \
--cc=aesteve@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=david@redhat.com \
--cc=dbassey@redhat.com \
--cc=farosas@suse.de \
--cc=hi@alyssa.is \
--cc=jasowang@redhat.com \
--cc=lvivier@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.com \
--cc=slp@redhat.com \
--cc=stevensd@chromium.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.