|
@@ -343,6 +343,29 @@ the addition of volatile memory support, it is now necessary to distinguish
|
|
|
between persistent and volatile memory backends. As such, memdev is deprecated
|
|
|
in favor of persistent-memdev.
|
|
|
|
|
|
+``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
|
|
|
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
+
|
|
|
+The 9p ``proxy`` filesystem backend driver has been deprecated and will be
|
|
|
+removed (along with its proxy helper daemon) in a future version of QEMU. Please
|
|
|
+use ``-fsdev local`` or ``-virtfs local`` for using the 9p ``local`` filesystem
|
|
|
+backend, or alternatively consider deploying virtiofsd instead.
|
|
|
+
|
|
|
+The 9p ``proxy`` backend was originally developed as an alternative to the 9p
|
|
|
+``local`` backend. The idea was to enhance security by dispatching actual low
|
|
|
+level filesystem operations from 9p server (QEMU process) over to a separate
|
|
|
+process (the virtfs-proxy-helper binary). However this alternative never gained
|
|
|
+momentum. The proxy backend is much slower than the local backend, hasn't seen
|
|
|
+any development in years, and showed to be less secure, especially due to the
|
|
|
+fact that its helper daemon must be run as root, whereas with the local backend
|
|
|
+QEMU is typically run as unprivileged user and allows to tighten behaviour by
|
|
|
+mapping permissions et al by using its 'mapped' security model option.
|
|
|
+
|
|
|
+Nowadays it would make sense to reimplement the ``proxy`` backend by using
|
|
|
+QEMU's ``vhost`` feature, which would eliminate the high latency costs under
|
|
|
+which the 9p ``proxy`` backend currently suffers. However as of to date nobody
|
|
|
+has indicated plans for such kind of reimplemention unfortunately.
|
|
|
+
|
|
|
|
|
|
Block device options
|
|
|
''''''''''''''''''''
|