vhost-user: Guarantee that memory regions do not overlap
Otherwise there would be an ambiguity problem. Suppose that: 1. There is a region from [0x40000, 0x50000) with mmap offset 0x500000. 2. There is a region from [0x48000, 0x58000) with mmap offset 0xA00000. A request has address 0x44000. Which mmap offset should be used? This problem appears with both guest and user addresses. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260522-vhost-user-dev-v1-1-b31646cf19b8@gmail.com>
Demi Marie Obenour committed
May 22, 2026 at 22:11 UTC
a63a6cd694cffa772e97bb37b0a304c8c7129397
1 file changed
+21
docs/interop/vhost-user.rst
+21
@@ -214,6 +214,18 @@ fields at the end.
214
215
:domid: a 32-bit Xen hypervisor specific domain id.
216
217
+For all memory regions active at a given time:
218
+
219
+- ``[guest address, guest address + size)`` of one memory region never overlaps
220
+ the ``[guest address, guest address + size)`` of another memory region.
221
+
222
+- ``[user address, user address + size)`` of one memory region never overlaps
223
+ the ``[user address, user address + size)`` of another memory region.
224
+
225
+Violating any of these is a bug in the front-end. This ensures that a guest
226
+address or user address always refers to at most one location in memory.
227
+The front-end must remove a region before it can add an overlapping one.
228
+
229
Single memory region description
230
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
231
@@ -745,6 +757,15 @@ The front-end sends a list of vhost memory regions to the back-end using the
757
``VHOST_USER_SET_MEM_TABLE`` message. Each region has two base
758
addresses: a guest address and a user address.
759
760
+Memory regions can be added via the ``VHOST_USER_ADD_MEM_REG`` message. They
761
+can be removed via the ``VHOST_USER_REM_MEM_REG`` message. These messages can
762
+only be used if the ``VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS`` protocol
763
+feature has been successfully negotiated.
764
+
765
+Guest addresses are physical addresses in the guest. User addresses are
766
+arbitrary opaque values, though they typically refer to userspace addresses in
767
+the client process.
768
+
769
Messages contain guest addresses and/or user addresses to reference locations
770
within the shared memory. The mapping of these addresses works as follows.
771