qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Albert Esteve <aesteve@redhat.com>, qemu-devel@nongnu.org
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	slp@redhat.com, hi@alyssa.is, mst@redhat.com,
	jasowang@redhat.com, stefanha@redhat.com,
	"Stefano Garzarella" <sgarzare@redhat.com>,
	stevensd@chromium.org
Subject: Re: [PATCH v3 1/5] vhost-user: Add VIRTIO Shared Memory map request
Date: Tue, 17 Sep 2024 12:07:53 +0200	[thread overview]
Message-ID: <abfd06b7-ad85-454b-a973-6c939c4588e3@redhat.com> (raw)
In-Reply-To: <20240912145335.129447-2-aesteve@redhat.com>

On 12.09.24 16:53, Albert Esteve wrote:
> Add SHMEM_MAP/UNMAP requests to vhost-user to
> handle VIRTIO Shared Memory mappings.
> 
> This request allows backends to dynamically map
> fds into a VIRTIO Shared Memory Region indentified
> by its `shmid`. Then, the fd memory is advertised
> to the driver as a base addres + offset, so it
> can be read/written (depending on the mmap flags
> requested) while its valid.
> 
> The backend can munmap the memory range
> in a given VIRTIO Shared Memory Region (again,
> identified by its `shmid`), to free it. Upon
> receiving this message, the front-end must
> mmap the regions with PROT_NONE to reserve
> the virtual memory space.
> 
> The device model needs to create MemoryRegion
> instances for the VIRTIO Shared Memory Regions
> and add them to the `VirtIODevice` instance.
> 
> Signed-off-by: Albert Esteve <aesteve@redhat.com>
> ---
>   hw/virtio/vhost-user.c                    | 122 ++++++++++++++++++++++
>   hw/virtio/virtio.c                        |  13 +++
>   include/hw/virtio/virtio.h                |   5 +
>   subprojects/libvhost-user/libvhost-user.c |  60 +++++++++++
>   subprojects/libvhost-user/libvhost-user.h |  52 +++++++++
>   5 files changed, 252 insertions(+)
> 
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index 00561daa06..338cc942ec 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -115,6 +115,8 @@ typedef enum VhostUserBackendRequest {
>       VHOST_USER_BACKEND_SHARED_OBJECT_ADD = 6,
>       VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE = 7,
>       VHOST_USER_BACKEND_SHARED_OBJECT_LOOKUP = 8,
> +    VHOST_USER_BACKEND_SHMEM_MAP = 9,
> +    VHOST_USER_BACKEND_SHMEM_UNMAP = 10,
>       VHOST_USER_BACKEND_MAX
>   }  VhostUserBackendRequest;
>   
> @@ -192,6 +194,24 @@ typedef struct VhostUserShared {
>       unsigned char uuid[16];
>   } VhostUserShared;
>   
> +/* For the flags field of VhostUserMMap */
> +#define VHOST_USER_FLAG_MAP_R (1u << 0)
> +#define VHOST_USER_FLAG_MAP_W (1u << 1)
> +
> +typedef struct {
> +    /* VIRTIO Shared Memory Region ID */
> +    uint8_t shmid;
> +    uint8_t padding[7];
> +    /* File offset */
> +    uint64_t fd_offset;
> +    /* Offset within the VIRTIO Shared Memory Region */
> +    uint64_t shm_offset;
> +    /* Size of the mapping */
> +    uint64_t len;
> +    /* Flags for the mmap operation, from VHOST_USER_FLAG_* */
> +    uint64_t flags;
> +} VhostUserMMap;
> +
>   typedef struct {
>       VhostUserRequest request;
>   
> @@ -224,6 +244,7 @@ typedef union {
>           VhostUserInflight inflight;
>           VhostUserShared object;
>           VhostUserTransferDeviceState transfer_state;
> +        VhostUserMMap mmap;
>   } VhostUserPayload;
>   
>   typedef struct VhostUserMsg {
> @@ -1749,6 +1770,100 @@ vhost_user_backend_handle_shared_object_lookup(struct vhost_user *u,
>       return 0;
>   }
>   
> +static int
> +vhost_user_backend_handle_shmem_map(struct vhost_dev *dev,
> +                                    VhostUserMMap *vu_mmap,
> +                                    int fd)
> +{
> +    void *addr = 0;
> +    MemoryRegion *mr = NULL;
> +
> +    if (fd < 0) {
> +        error_report("Bad fd for map");
> +        return -EBADF;
> +    }
> +
> +    if (!dev->vdev->shmem_list ||
> +        dev->vdev->n_shmem_regions <= vu_mmap->shmid) {
> +        error_report("Device only has %d VIRTIO Shared Memory Regions. "
> +                     "Requested ID: %d",
> +                     dev->vdev->n_shmem_regions, vu_mmap->shmid);
> +        return -EFAULT;
> +    }
> +
> +    mr = &dev->vdev->shmem_list[vu_mmap->shmid];
> +
> +    if (!mr) {
> +        error_report("VIRTIO Shared Memory Region at "
> +                     "ID %d unitialized", vu_mmap->shmid);
> +        return -EFAULT;
> +    }
> +
> +    if ((vu_mmap->shm_offset + vu_mmap->len) < vu_mmap->len ||
> +        (vu_mmap->shm_offset + vu_mmap->len) > mr->size) {
> +        error_report("Bad offset/len for mmap %" PRIx64 "+%" PRIx64,
> +                     vu_mmap->shm_offset, vu_mmap->len);
> +        return -EFAULT;
> +    }
> +
> +    void *shmem_ptr = memory_region_get_ram_ptr(mr);
> +
> +    addr = mmap(shmem_ptr + vu_mmap->shm_offset, vu_mmap->len,
> +        ((vu_mmap->flags & VHOST_USER_FLAG_MAP_R) ? PROT_READ : 0) |
> +        ((vu_mmap->flags & VHOST_USER_FLAG_MAP_W) ? PROT_WRITE : 0),
> +        MAP_SHARED | MAP_FIXED, fd, vu_mmap->fd_offset);
> +

I'm sorry, but that looks completely wrong. You cannot just take some 
RAM memory region/ RAMBlock that has properly set flags/fd/whatssoever 
and map whatever you want in there.

Likely you would need a distinct RAMBlock/RAM memory region per mmap(), 
and would end up mmaping implicitly via qemu_ram_mmap().

Then, your shared region would simply be an empty container into which 
you map these RAM memory regions.

-- 
Cheers,

David / dhildenb



  parent reply	other threads:[~2024-09-17 10:08 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-12 14:53 [PATCH v3 0/5] vhost-user: Add SHMEM_MAP/UNMAP requests Albert Esteve
2024-09-12 14:53 ` [PATCH v3 1/5] vhost-user: Add VIRTIO Shared Memory map request Albert Esteve
2024-09-16 17:21   ` Stefan Hajnoczi
2024-11-25  9:55     ` Albert Esteve
2024-09-17 10:07   ` David Hildenbrand [this message]
2024-11-25  8:28     ` Albert Esteve
2024-11-27 10:50       ` David Hildenbrand
2024-11-27 12:10         ` David Hildenbrand
2024-11-27 12:17           ` David Hildenbrand
2024-11-27 12:31             ` Albert Esteve
2024-11-27 12:40               ` David Hildenbrand
2024-11-27 12:55         ` Albert Esteve
2024-09-12 14:53 ` [PATCH v3 2/5] virtio: Track shared memory mappings Albert Esteve
2024-09-16 17:27   ` Stefan Hajnoczi
2024-09-12 14:53 ` [PATCH v3 3/5] vhost_user: Add frontend command for shmem config Albert Esteve
2024-09-17  7:48   ` Stefan Hajnoczi
2024-09-17  7:50   ` Stefan Hajnoczi
2024-09-12 14:53 ` [PATCH v3 4/5] vhost-user-dev: Add cache BAR Albert Esteve
2024-09-17  8:27   ` Stefan Hajnoczi
2024-11-25 16:16     ` Albert Esteve
2024-11-26  7:55       ` Albert Esteve
2024-11-26 12:51     ` Albert Esteve
2024-09-17  8:32   ` Stefan Hajnoczi
2024-09-17  8:36     ` Stefan Hajnoczi
2024-09-12 14:53 ` [PATCH v3 5/5] vhost_user: Add MEM_READ/WRITE backend requests Albert Esteve
2024-09-12 14:59 ` [PATCH v3 0/5] vhost-user: Add SHMEM_MAP/UNMAP requests Albert Esteve
2024-09-16 17:57 ` Stefan Hajnoczi
2024-09-17  7:05   ` Albert Esteve
2024-09-17  7:43     ` Stefan Hajnoczi

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=abfd06b7-ad85-454b-a973-6c939c4588e3@redhat.com \
    --to=david@redhat.com \
    --cc=aesteve@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=hi@alyssa.is \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sgarzare@redhat.com \
    --cc=slp@redhat.com \
    --cc=stefanha@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).