f21e95ee97
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> |
||
---|---|---|
.. | ||
_templates | ||
about | ||
config | ||
devel | ||
interop | ||
specs | ||
sphinx | ||
sphinx-static | ||
spin | ||
system | ||
tools | ||
user | ||
block-replication.txt | ||
bypass-iommu.txt | ||
COLO-FT.txt | ||
colo-proxy.txt | ||
conf.py | ||
defs.rst.inc | ||
igd-assign.txt | ||
image-fuzzer.txt | ||
index.rst | ||
memory-hotplug.txt | ||
meson.build | ||
multi-thread-compression.txt | ||
multiseat.txt | ||
nvdimm.txt | ||
pci_expander_bridge.txt | ||
pcie_pci_bridge.txt | ||
pcie_sriov.txt | ||
pcie.txt | ||
pvrdma.txt | ||
qcow2-cache.txt | ||
qdev-device-use.txt | ||
qemu-option-trace.rst.inc | ||
qemupciserial.inf | ||
rdma.txt | ||
spice-port-fqdn.txt | ||
throttle.txt | ||
u2f.txt | ||
xbzrle.txt | ||
xen-save-devices-state.txt |