From: Albert Esteve <aesteve@redhat.com>
To: qemu-devel@nongnu.org
Cc: jasowang@redhat.com, david@redhat.com, slp@redhat.com,
"Alex Bennée" <alex.bennee@linaro.org>,
stefanha@redhat.com, "Michael S. Tsirkin" <mst@redhat.com>,
"Albert Esteve" <aesteve@redhat.com>
Subject: [RFC PATCH v2 0/5] vhost-user: Add SHMEM_MAP/UNMAP requests
Date: Fri, 28 Jun 2024 16:57:05 +0200 [thread overview]
Message-ID: <20240628145710.1516121-1-aesteve@redhat.com> (raw)
Hi all,
v1->v2:
- Corrected typos and clarifications from
first review
- Added SHMEM_CONFIG frontend request to
query VIRTIO shared memory regions from
backends
- vhost-user-device to use SHMEM_CONFIG
to request and initialise regions
- Added MEM_READ/WRITE backend requests
in case address translation fails
accessing VIRTIO Shared Memory Regions
with MMAPs
This is an update of my attempt to have
backends support dynamic fd mapping into VIRTIO
Shared Memory Regions. After the first review
I have added more commits and new messages
to the vhost-user protocol.
However, I still have some doubts as to
how will this work, specially regarding
the MEM_READ and MEM_WRITE commands.
Thus, I am still looking for feedback,
to ensure that I am going in the right
direction with the implementation.
The usecase for this patch is, e.g., to support
vhost-user-gpu RESOURCE_BLOB operations,
or DAX Window request for virtio-fs. In
general, any operation where a backend
need to request the frontend to mmap an
fd into a VIRTIO Shared Memory Region,
so that the guest can then access it.
After receiving the SHMEM_MAP/UNMAP request,
the frontend will perform the mmap with the
instructed parameters (i.e., shmid, shm_offset,
fd_offset, fd, lenght).
As there are already a couple devices
that could benefit of such a feature,
and more could require it in the future,
the goal is to make the implementation
generic.
To that end, the VIRTIO Shared Memory
Region list is declared in the `VirtIODevice`
struct.
This patch also includes:
SHMEM_CONFIG frontend request that is
specifically meant to allow generic
vhost-user-device frontend to be able to
query VIRTIO Shared Memory settings from the
backend (as this device is generic and agnostic
of the actual backend configuration).
Finally, MEM_READ/WRITE backend requests are
added to deal with a potential issue when having
any backend sharing a descriptor that references
a mapping to another backend. The first
backend will not be able to see these
mappings. So these requests are a fallback
for vhost-user memory translation fails.
Albert Esteve (5):
vhost-user: Add VIRTIO Shared Memory map request
vhost_user: Add frontend command for shmem config
vhost-user-dev: Add cache BAR
vhost_user: Add MEM_READ/WRITE backend requests
vhost_user: Implement mem_read/mem_write handlers
docs/interop/vhost-user.rst | 58 ++++++
hw/virtio/vhost-user-base.c | 39 +++-
hw/virtio/vhost-user-device-pci.c | 37 +++-
hw/virtio/vhost-user.c | 221 ++++++++++++++++++++++
hw/virtio/virtio.c | 12 ++
include/hw/virtio/vhost-backend.h | 6 +
include/hw/virtio/vhost-user.h | 1 +
include/hw/virtio/virtio.h | 5 +
subprojects/libvhost-user/libvhost-user.c | 149 +++++++++++++++
subprojects/libvhost-user/libvhost-user.h | 91 +++++++++
10 files changed, 614 insertions(+), 5 deletions(-)
--
2.45.2
next reply other threads:[~2024-06-28 14:58 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 14:57 Albert Esteve [this message]
2024-06-28 14:57 ` [RFC PATCH v2 1/5] vhost-user: Add VIRTIO Shared Memory map request Albert Esteve
2024-07-11 7:45 ` Stefan Hajnoczi
2024-09-03 9:54 ` Albert Esteve
2024-09-03 11:54 ` Albert Esteve
2024-09-05 16:45 ` Stefan Hajnoczi
2024-09-11 11:57 ` Albert Esteve
2024-09-11 14:54 ` Stefan Hajnoczi
2024-09-04 7:28 ` Albert Esteve
2024-06-28 14:57 ` [RFC PATCH v2 2/5] vhost_user: Add frontend command for shmem config Albert Esteve
2024-07-11 8:10 ` Stefan Hajnoczi
2024-09-04 9:05 ` Albert Esteve
2024-07-11 8:15 ` Stefan Hajnoczi
2024-06-28 14:57 ` [RFC PATCH v2 3/5] vhost-user-dev: Add cache BAR Albert Esteve
2024-07-11 8:25 ` Stefan Hajnoczi
2024-09-04 11:20 ` Albert Esteve
2024-06-28 14:57 ` [RFC PATCH v2 4/5] vhost_user: Add MEM_READ/WRITE backend requests Albert Esteve
2024-07-11 8:53 ` Stefan Hajnoczi
2024-06-28 14:57 ` [RFC PATCH v2 5/5] vhost_user: Implement mem_read/mem_write handlers Albert Esteve
2024-07-11 8:55 ` Stefan Hajnoczi
2024-09-04 13:01 ` Albert Esteve
2024-09-05 19:18 ` Stefan Hajnoczi
2024-09-10 7:14 ` Albert Esteve
2024-07-11 9:01 ` [RFC PATCH v2 0/5] vhost-user: Add SHMEM_MAP/UNMAP requests Stefan Hajnoczi
2024-07-11 10:56 ` Alyssa Ross
2024-07-12 2:06 ` David Stevens
2024-07-12 5:47 ` Michael S. Tsirkin
2024-07-15 2:30 ` Jason Wang
2024-07-16 1:21 ` David Stevens
2024-09-03 8:42 ` Albert Esteve
2024-09-05 16:39 ` Stefan Hajnoczi
2024-09-06 7:03 ` Albert Esteve
2024-09-06 13:15 ` Stefan Hajnoczi
2024-09-05 15:56 ` Stefan Hajnoczi
2024-09-06 4:18 ` David Stevens
2024-09-06 13:00 ` 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=20240628145710.1516121-1-aesteve@redhat.com \
--to=aesteve@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=david@redhat.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=slp@redhat.com \
--cc=stefanha@redhat.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;
as well as URLs for NNTP newsgroup(s).