diff options
author | Viresh Kumar <viresh.kumar@linaro.org> | 2023-03-09 14:21:01 +0530 |
---|---|---|
committer | Michael S. Tsirkin <mst@redhat.com> | 2023-04-21 04:25:52 -0400 |
commit | f21e95ee97d5adb4a274b48c6c8f70a221c1f513 (patch) | |
tree | e35e894534f5452b628a8b4fb54d9e833ffd2011 /monitor | |
parent | 17c67f6849551b2bbffb7a3a8b490b853df86129 (diff) | |
download | qemu-f21e95ee97d5adb4a274b48c6c8f70a221c1f513.zip qemu-f21e95ee97d5adb4a274b48c6c8f70a221c1f513.tar.gz qemu-f21e95ee97d5adb4a274b48c6c8f70a221c1f513.tar.bz2 |
docs: vhost-user: Add Xen specific memory mapping support
The current model of memory mapping at the back-end works fine where a
standard call to mmap() (for the respective file descriptor) is enough
before the front-end can start accessing the guest memory.
There are other complex cases though where the back-end needs more
information and simple mmap() isn't enough. For example Xen, a type-1
hypervisor, currently supports memory mapping via two different methods,
foreign-mapping (via /dev/privcmd) and grant-dev (via /dev/gntdev). In
both these cases, the back-end needs to call mmap() and ioctl(), with
extra information like the Xen domain-id of the guest whose memory we
are trying to map.
Add a new protocol feature, 'VHOST_USER_PROTOCOL_F_XEN_MMAP', which lets
the back-end know about the additional memory mapping requirements.
When this feature is negotiated, the front-end will send the additional
information within the memory regions themselves.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <6d0bd7f0e1aeec3ddb603ae4ff334c75c7d0d7b3.1678351495.git.viresh.kumar@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Diffstat (limited to 'monitor')
0 files changed, 0 insertions, 0 deletions