[PATCH 2/2] Reflect in virtiofs.rst that virtiofs can be used without NUMA

Marc Hartmayer mhartmay at linux.ibm.com
Tue Oct 13 16:53:12 UTC 2020

From: Halil Pasic <pasic at linux.ibm.com>

Reflect in the virtiofs documentation that virtiofs can now be used
even without NUMA. While at it, be more precise where and why shared
memory is required.

Signed-off-by: Halil Pasic <pasic at linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay at linux.ibm.com>
 docs/kbase/virtiofs.rst | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/docs/kbase/virtiofs.rst b/docs/kbase/virtiofs.rst
index dea8e79f833c..01440420d76d 100644
--- a/docs/kbase/virtiofs.rst
+++ b/docs/kbase/virtiofs.rst
@@ -16,10 +16,17 @@ See https://virtio-fs.gitlab.io/
 Host setup
-The host-side virtiofsd daemon, like other vhost-user backed devices,
-requires shared memory between the host and the guest. As of QEMU 4.2, this
-requires specifying a NUMA topology for the guest and explicitly specifying
-a memory backend. Multiple options are available:
+Almost all virtio devices (all that use virtqueues) require access to
+at least certain portions of guest RAM (possibly policed by DMA). In
+case of virtiofsd, much like in case of other vhost-user (see
+https://www.qemu.org/docs/master/interop/vhost-user.html) virtio
+devices that are realized by an userspace process, this in practice
+means that QEMU needs to allocate the backing memory for all the guest
+RAM as shared memory. As of QEMU 4.2, it is possible to explicitly
+specify a memory backend when specifying the NUMA topology. This
+method is however only viable for machine types that do support
+NUMA. As of QEMU 5.0.0, it is possible to specify the memory backend
+without NUMA (using the so called memobject interface).
 Either of the following:
@@ -46,7 +53,7 @@ Either of the following:
 Guest setup
-#. Specify the NUMA topology
+#. Specify the NUMA topology (this step is only required for the NUMA case)
    in the domain XML of the guest.
    For the simplest one-node topology for a guest with 2GiB of RAM and 8 vCPUs:

More information about the libvir-list mailing list