[PATCH 0/9] vhost-user: support any POSIX system (tested on macOS and FreeBSD)

[PATCH 0/9] vhost-user: support any POSIX system (tested on macOS and FreeBSD)

[Stefano Garzarella]

The vhost-user protocol is not really Linux-specific, so let's try support
QEMU's frontends and backends (including libvhost-user) in any POSIX system
with this series. The main use case is to be able to use virtio devices that
we don't have built-in in QEMU (e.g. virtiofsd, vhost-user-vsock, etc.) even
in non-Linux systems.

The first 5 patches are more like fixes discovered at runtime on macOS or
FreeBSD that could go even independently of this series.

Patches 6, 7, and 8 enable building of frontends and backends (including
libvhost-user) with associated code changes to succeed in compilation.

The latest patch (9) adds support for the POSIX shm_open() API to create
shared memory which is identified by an fd that can be shared with vhost-user
backends. This is useful on those systems (like macOS) where we don't have
memfd_create() or special filesystems like "/dev/shm".

I put the whole series in RFC because I have some questions especially in
patch 6 and 9, but in general any comment/suggestion/test are really welcome.

Maybe the first 5 patches can go separately, but I only discovered those
problems after testing patches 6 - 9, so I have included them in this series
for now. Please let me know if you prefer that I send them separately.

For now I tested this series using vhost-user-blk and QSD on
macOS Sonoma 14.3.1 (aarch64), FreeBSD 14 (x86_64), and Fedora 39 (x86_64)
in this way:

- Start vhost-user-blk or QSD (same commands for all systems)

  vhost-user-blk -s /tmp/vhost.socket \
    -b Fedora-Cloud-Base-39-1.5.x86_64.raw

  qemu-storage-daemon \
    --blockdev file,filename=Fedora-Cloud-Base-39-1.5.x86_64.qcow2,node-name=file \
    --blockdev qcow2,file=file,node-name=qcow2 \
    --export vhost-user-blk,addr.type=unix,addr.path=/tmp/vhost.socket,id=vub,num-queues=1,node-name=qcow2,writable=on

- macOS (aarch64): start QEMU (using hvf accelerator)

  qemu-system-aarch64 -smp 2 -cpu host -M virt,accel=hvf,memory-backend=mem \
    -drive file=./build/pc-bios/edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on \
    -device virtio-net-device,netdev=net0 -netdev user,id=net0 \
    -device ramfb -device usb-ehci -device usb-kbd \
    -object memory-backend-file,mem-path="/mem0",shm=on,share=on,id=mem,size=512M \
    -device vhost-user-blk-pci,num-queues=1,disable-legacy=on,chardev=char0 \
    -chardev socket,id=char0,path=/tmp/vhost.socket

- FreeBSD (x86_64): start QEMU (no accelerators available)

  qemu-system-x86_64 -smp 2 -M q35,memory-backend=mem \
    -object memory-backend-file,mem-path="/mem0",shm=on,share=on,id=mem,size="512M" \
    -device vhost-user-blk-pci,num-queues=1,chardev=char0 \
    -chardev socket,id=char0,path=/tmp/vhost.socket

- Fedora (x86_64): start QEMU (using kvm accelerator)

  qemu-system-x86_64 -smp 2 -M q35,accel=kvm,memory-backend=mem \
    -object memory-backend-file,mem-path="/mem0",shm=on,share=on,id=mem,size="512M" \
    -device vhost-user-blk-pci,num-queues=1,chardev=char0 \
    -chardev socket,id=char0,path=/tmp/vhost.socket

Thanks,
Stefano

Stefano Garzarella (9):
  libvhost-user: set msg.msg_control to NULL when it is empty
  libvhost-user: fail vu_message_write() if sendmsg() is failing
  libvhost-user: mask F_INFLIGHT_SHMFD if memfd is not supported
  vhost-user-server: don't abort if we can't set fd non-blocking
  contrib/vhost-user-blk: fix bind() using the right size of the address
  vhost-user: enable frontends on any POSIX system
  libvhost-user: enable it on any POSIX system
  contrib/vhost-user-blk: enabled it on any POSIX system
  hostmem-file: support POSIX shm_open()

 meson.build                               |  5 +-
 qapi/qom.json                             |  4 ++
 subprojects/libvhost-user/libvhost-user.h |  2 +-
 backends/hostmem-file.c                   | 57 ++++++++++++++++-
 contrib/vhost-user-blk/vhost-user-blk.c   | 23 +++++--
 hw/net/vhost_net.c                        |  8 ++-
 subprojects/libvhost-user/libvhost-user.c | 76 ++++++++++++++++++++++-
 util/vhost-user-server.c                  |  6 +-
 backends/meson.build                      |  2 +-
 hw/block/Kconfig                          |  2 +-
 qemu-options.hx                           | 10 ++-
 util/meson.build                          |  4 +-
 12 files changed, 179 insertions(+), 20 deletions(-)

-- 
2.43.2

[PATCH 1/9] libvhost-user: set msg.msg_control to NULL when it is empty

[Stefano Garzarella]

From: Stefano Garzarella <stefanogarzarella@gmail.com>

On some OS (e.g. macOS) sendmsg() returns -1 (errno EINVAL) if
the `struct msghdr` has the field `msg_controllen` set to 0, but
`msg_control` is not NULL.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
 subprojects/libvhost-user/libvhost-user.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvhost-user/libvhost-user.c
index a3b158c671..b9c18eee53 100644
--- a/subprojects/libvhost-user/libvhost-user.c
+++ b/subprojects/libvhost-user/libvhost-user.c
@@ -387,6 +387,7 @@ vu_message_write(VuDev *dev, int conn_fd, VhostUserMsg *vmsg)
         memcpy(CMSG_DATA(cmsg), vmsg->fds, fdsize);
     } else {
         msg.msg_controllen = 0;
+        msg.msg_control = NULL;
     }
 
     do {
-- 
2.43.2

[PATCH 2/9] libvhost-user: fail vu_message_write() if sendmsg() is failing

[Stefano Garzarella]

In vu_message_write() we use sendmsg() to send the message header,
then a write() to send the payload.

If sendmsg() fails we should avoid sending the payload, since we
were unable to send the header.

Discovered before fixing the issue with the previous patch, where
sendmsg() failed on macOS due to wrong parameters, but the frontend
still sent the payload which the backend incorrectly interpreted
as a wrong header.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
 subprojects/libvhost-user/libvhost-user.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvhost-user/libvhost-user.c
index b9c18eee53..527a550345 100644
--- a/subprojects/libvhost-user/libvhost-user.c
+++ b/subprojects/libvhost-user/libvhost-user.c
@@ -394,6 +394,11 @@ vu_message_write(VuDev *dev, int conn_fd, VhostUserMsg *vmsg)
         rc = sendmsg(conn_fd, &msg, 0);
     } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
 
+    if (rc <= 0) {
+        vu_panic(dev, "Error while writing: %s", strerror(errno));
+        return false;
+    }
+
     if (vmsg->size) {
         do {
             if (vmsg->data) {
-- 
2.43.2

[PATCH 3/9] libvhost-user: mask F_INFLIGHT_SHMFD if memfd is not supported

[Stefano Garzarella]

libvhost-user will panic when receiving VHOST_USER_GET_INFLIGHT_FD
message if MFD_ALLOW_SEALING is not defined, since it's not able
to create a memfd.

VHOST_USER_GET_INFLIGHT_FD is used only if
VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD is negotiated. So, let's mask
that feature if the backend is not able to properly handle these
messages.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
 subprojects/libvhost-user/libvhost-user.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvhost-user/libvhost-user.c
index 527a550345..5da8de838b 100644
--- a/subprojects/libvhost-user/libvhost-user.c
+++ b/subprojects/libvhost-user/libvhost-user.c
@@ -1610,6 +1610,16 @@ vu_get_protocol_features_exec(VuDev *dev, VhostUserMsg *vmsg)
         features |= dev->iface->get_protocol_features(dev);
     }
 
+    /*
+     * If MFD_ALLOW_SEALING is not defined, we are not able to handle
+     * VHOST_USER_GET_INFLIGHT_FD messages, since we can't create a memfd.
+     * Those messages are used only if VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
+     * is negotiated. A device implementation can enable it, so let's mask
+     * it to avoid a runtime panic.
+     */
+#ifndef MFD_ALLOW_SEALING
+    features &= ~(1ULL << VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD);
+#endif
     vmsg_set_reply_u64(vmsg, features);
     return true;
 }
-- 
2.43.2

[PATCH 4/9] vhost-user-server: don't abort if we can't set fd non-blocking

[Stefano Garzarella]

From: Stefano Garzarella <stefanogarzarella@gmail.com>

In vhost-user-server we set all fd received from the other peer
in non-blocking mode. For some of them (e.g. memfd, shm_open, etc.)
if we fail, it's not really a problem, because we don't use these
fd with blocking operations, but only to map memory.

In these cases a failure is not bad, so let's just report a warning
instead of panicking if we fail to set some fd in non-blocking mode.

This for example occurs in macOS where setting shm_open() fd
non-blocking is failing (errno -25).

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
 util/vhost-user-server.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/util/vhost-user-server.c b/util/vhost-user-server.c
index 3bfb1ad3ec..064999f0b7 100644
--- a/util/vhost-user-server.c
+++ b/util/vhost-user-server.c
@@ -66,7 +66,11 @@ static void vmsg_unblock_fds(VhostUserMsg *vmsg)
 {
     int i;
     for (i = 0; i < vmsg->fd_num; i++) {
-        qemu_socket_set_nonblock(vmsg->fds[i]);
+        int ret = qemu_socket_try_set_nonblock(vmsg->fds[i]);
+        if (ret) {
+            warn_report("Failed to set fd %d nonblock for request %d: %s",
+                        vmsg->fds[i], vmsg->request, strerror(-ret));
+        }
     }
 }
 
-- 
2.43.2

[PATCH 5/9] contrib/vhost-user-blk: fix bind() using the right size of the address

[Stefano Garzarella]

From: Stefano Garzarella <stefanogarzarella@gmail.com>

On macOS passing `-s /tmp/vhost.socket` parameter to the vhost-user-blk
application, the bind was done on `/tmp/vhost.socke` pathname,
missing the last character.

This sounds like one of the portability problems described in the
unix(7) manpage:

   Pathname sockets
       When  binding  a socket to a pathname, a few rules should
       be observed for maximum portability and ease of coding:

       •  The pathname in sun_path should be null-terminated.

       •  The length of the pathname, including the  terminating
          null byte, should not exceed the size of sun_path.

       •  The  addrlen  argument  that  describes  the enclosing
          sockaddr_un structure should have a value of at least:

              offsetof(struct sockaddr_un, sun_path) +
              strlen(addr.sun_path)+1

          or,  more  simply,  addrlen  can   be   specified   as
          sizeof(struct sockaddr_un).

So let's follow the last advice and simplify the code as well.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
 contrib/vhost-user-blk/vhost-user-blk.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/contrib/vhost-user-blk/vhost-user-blk.c b/contrib/vhost-user-blk/vhost-user-blk.c
index 89e5f11a64..a8ab9269a2 100644
--- a/contrib/vhost-user-blk/vhost-user-blk.c
+++ b/contrib/vhost-user-blk/vhost-user-blk.c
@@ -469,7 +469,6 @@ static int unix_sock_new(char *unix_fn)
 {
     int sock;
     struct sockaddr_un un;
-    size_t len;
 
     assert(unix_fn);
 
@@ -481,10 +480,9 @@ static int unix_sock_new(char *unix_fn)
 
     un.sun_family = AF_UNIX;
     (void)snprintf(un.sun_path, sizeof(un.sun_path), "%s", unix_fn);
-    len = sizeof(un.sun_family) + strlen(un.sun_path);
 
     (void)unlink(unix_fn);
-    if (bind(sock, (struct sockaddr *)&un, len) < 0) {
+    if (bind(sock, (struct sockaddr *)&un, sizeof(un)) < 0) {
         perror("bind");
         goto fail;
     }
-- 
2.43.2

[PATCH 6/9] vhost-user: enable frontends on any POSIX system

[Stefano Garzarella]

The vhost-user protocol is not really Linux-specific so let's enable
vhost-user frontends for any POSIX system.

In vhost_net.c we use VHOST_FILE_UNBIND which is defined in a Linux
specific header, let's define it for other systems as well.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
If we want to be more conservative, maybe we can leave `have_vhost_user`
auto only on linux. I removed it more to test with CI if we have any
problems in the other POSIX systems.

In hw/net/vhost_net.c maybe we can just do:
 #ifndef VHOST_FILE_UNBIND
 #define VHOST_FILE_UNBIND -1
 #endif

Any suggestion?

Thanks,
Stefano
---
 meson.build        | 1 -
 hw/net/vhost_net.c | 8 +++++++-
 hw/block/Kconfig   | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/meson.build b/meson.build
index 0ef1654e86..462f2d7593 100644
--- a/meson.build
+++ b/meson.build
@@ -151,7 +151,6 @@ have_tpm = get_option('tpm') \
 
 # vhost
 have_vhost_user = get_option('vhost_user') \
-  .disable_auto_if(host_os != 'linux') \
   .require(host_os != 'windows',
            error_message: 'vhost-user is not available on Windows').allowed()
 have_vhost_vdpa = get_option('vhost_vdpa') \
diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
index e8e1661646..346ef74eb1 100644
--- a/hw/net/vhost_net.c
+++ b/hw/net/vhost_net.c
@@ -34,8 +34,14 @@
 #include "standard-headers/linux/virtio_ring.h"
 #include "hw/virtio/vhost.h"
 #include "hw/virtio/virtio-bus.h"
-#include "linux-headers/linux/vhost.h"
 
+#if defined(__linux__)
+#include "linux-headers/linux/vhost.h"
+#else
+#ifndef VHOST_FILE_UNBIND
+#define VHOST_FILE_UNBIND -1
+#endif
+#endif
 
 /* Features supported by host kernel. */
 static const int kernel_feature_bits[] = {
diff --git a/hw/block/Kconfig b/hw/block/Kconfig
index 9e8f28f982..29ee09e434 100644
--- a/hw/block/Kconfig
+++ b/hw/block/Kconfig
@@ -40,7 +40,7 @@ config VHOST_USER_BLK
     bool
     # Only PCI devices are provided for now
     default y if VIRTIO_PCI
-    depends on VIRTIO && VHOST_USER && LINUX
+    depends on VIRTIO && VHOST_USER
 
 config SWIM
     bool
-- 
2.43.2

[PATCH 7/9] libvhost-user: enable it on any POSIX system

[Stefano Garzarella]

The vhost-user protocol is not really Linux-specific so let's enable
libvhost-user for any POSIX system.

Compiling it on macOS and FreeBSD some problems came up:
- avoid to include linux/vhost.h which is avaibale only on Linux
  (vhost_types.h contains many of the things we need)
- macOS doesn't provide sys/endian.h, so let's define them
  (note: libvhost-user doesn't include qemu's headers, so we can't use
   use "qemu/bswap.h")
- define eventfd_[write|read] as write/read wrapper when system doesn't
  provide those (e.g. macOS)
- copy SEAL defines from include/qemu/memfd.h to make the code works
  on FreeBSD where MFD_ALLOW_SEALING is defined
- define MAP_NORESERVE if it's not defined (e.g. on FreeBSD)

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
 meson.build                               |  2 +-
 subprojects/libvhost-user/libvhost-user.h |  2 +-
 subprojects/libvhost-user/libvhost-user.c | 60 +++++++++++++++++++++--
 3 files changed, 59 insertions(+), 5 deletions(-)

diff --git a/meson.build b/meson.build
index 462f2d7593..af15178969 100644
--- a/meson.build
+++ b/meson.build
@@ -3188,7 +3188,7 @@ endif
 config_host_data.set('CONFIG_FDT', fdt.found())
 
 vhost_user = not_found
-if host_os == 'linux' and have_vhost_user
+if have_vhost_user
   libvhost_user = subproject('libvhost-user')
   vhost_user = libvhost_user.get_variable('vhost_user_dep')
 endif
diff --git a/subprojects/libvhost-user/libvhost-user.h b/subprojects/libvhost-user/libvhost-user.h
index c2352904f0..e684b999b4 100644
--- a/subprojects/libvhost-user/libvhost-user.h
+++ b/subprojects/libvhost-user/libvhost-user.h
@@ -18,9 +18,9 @@
 #include <stdbool.h>
 #include <stddef.h>
 #include <poll.h>
-#include <linux/vhost.h>
 #include <pthread.h>
 #include "standard-headers/linux/virtio_ring.h"
+#include "standard-headers/linux/vhost_types.h"
 
 /* Based on qemu/hw/virtio/vhost-user.c */
 #define VHOST_USER_F_PROTOCOL_FEATURES 30
diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvhost-user/libvhost-user.c
index 5da8de838b..1075fd3147 100644
--- a/subprojects/libvhost-user/libvhost-user.c
+++ b/subprojects/libvhost-user/libvhost-user.c
@@ -28,9 +28,7 @@
 #include <inttypes.h>
 #include <sys/types.h>
 #include <sys/socket.h>
-#include <sys/eventfd.h>
 #include <sys/mman.h>
-#include <endian.h>
 
 /* Necessary to provide VIRTIO_F_VERSION_1 on system
  * with older linux headers. Must appear before
@@ -39,8 +37,8 @@
 #include "standard-headers/linux/virtio_config.h"
 
 #if defined(__linux__)
+#include <endian.h>
 #include <sys/syscall.h>
-#include <fcntl.h>
 #include <sys/ioctl.h>
 #include <linux/vhost.h>
 
@@ -50,6 +48,62 @@
 
 #endif
 
+#if defined(__APPLE__) && (__MACH__)
+#include <libkern/OSByteOrder.h>
+#define htobe16(x) OSSwapHostToBigInt16(x)
+#define htole16(x) OSSwapHostToLittleInt16(x)
+#define be16toh(x) OSSwapBigToHostInt16(x)
+#define le16toh(x) OSSwapLittleToHostInt16(x)
+
+#define htobe32(x) OSSwapHostToBigInt32(x)
+#define htole32(x) OSSwapHostToLittleInt32(x)
+#define be32toh(x) OSSwapBigToHostInt32(x)
+#define le32toh(x) OSSwapLittleToHostInt32(x)
+
+#define htobe64(x) OSSwapHostToBigInt64(x)
+#define htole64(x) OSSwapHostToLittleInt64(x)
+#define be64toh(x) OSSwapBigToHostInt64(x)
+#define le64toh(x) OSSwapLittleToHostInt64(x)
+#endif
+
+#ifdef CONFIG_EVENTFD
+#include <sys/eventfd.h>
+#else
+#define eventfd_t uint64_t
+
+int eventfd_write(int fd, eventfd_t value)
+{
+    return (write(fd, &value, sizeof(value)) == sizeof(value)) ? 0 : -1;
+}
+
+int eventfd_read(int fd, eventfd_t *value)
+{
+    return (read(fd, value, sizeof(*value)) == sizeof(*value)) ? 0 : -1;
+}
+#endif
+
+#ifdef MFD_ALLOW_SEALING
+#include <fcntl.h>
+
+#ifndef F_LINUX_SPECIFIC_BASE
+#define F_LINUX_SPECIFIC_BASE 1024
+#endif
+
+#ifndef F_ADD_SEALS
+#define F_ADD_SEALS (F_LINUX_SPECIFIC_BASE + 9)
+#define F_GET_SEALS (F_LINUX_SPECIFIC_BASE + 10)
+
+#define F_SEAL_SEAL     0x0001  /* prevent further seals from being set */
+#define F_SEAL_SHRINK   0x0002  /* prevent file from shrinking */
+#define F_SEAL_GROW     0x0004  /* prevent file from growing */
+#define F_SEAL_WRITE    0x0008  /* prevent writes */
+#endif
+#endif
+
+#ifndef MAP_NORESERVE
+#define MAP_NORESERVE 0
+#endif
+
 #include "include/atomic.h"
 
 #include "libvhost-user.h"
-- 
2.43.2

[PATCH 8/9] contrib/vhost-user-blk: enabled it on any POSIX system

[Stefano Garzarella]

Let's make the code more portable by using the "qemu/bswap.h" API
and adding defines from block/file-posix.c to support O_DIRECT in
other systems (e.g. macOS).

vhost-user-server.c is a dependency, let's enable it for any POSIX
system.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
 meson.build                             |  2 --
 contrib/vhost-user-blk/vhost-user-blk.c | 19 +++++++++++++++++--
 util/meson.build                        |  4 +++-
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/meson.build b/meson.build
index af15178969..8afda86d3d 100644
--- a/meson.build
+++ b/meson.build
@@ -1954,8 +1954,6 @@ has_statx = cc.has_header_symbol('sys/stat.h', 'STATX_BASIC_STATS', prefix: gnu_
 has_statx_mnt_id = cc.has_header_symbol('sys/stat.h', 'STATX_MNT_ID', prefix: gnu_source_prefix)
 
 have_vhost_user_blk_server = get_option('vhost_user_blk_server') \
-  .require(host_os == 'linux',
-           error_message: 'vhost_user_blk_server requires linux') \
   .require(have_vhost_user,
            error_message: 'vhost_user_blk_server requires vhost-user support') \
   .disable_auto_if(not have_tools and not have_system) \
diff --git a/contrib/vhost-user-blk/vhost-user-blk.c b/contrib/vhost-user-blk/vhost-user-blk.c
index a8ab9269a2..462e584857 100644
--- a/contrib/vhost-user-blk/vhost-user-blk.c
+++ b/contrib/vhost-user-blk/vhost-user-blk.c
@@ -16,6 +16,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/bswap.h"
 #include "standard-headers/linux/virtio_blk.h"
 #include "libvhost-user-glib.h"
 
@@ -24,6 +25,20 @@
 #include <sys/ioctl.h>
 #endif
 
+/* OS X does not have O_DSYNC */
+#ifndef O_DSYNC
+#ifdef O_SYNC
+#define O_DSYNC O_SYNC
+#elif defined(O_FSYNC)
+#define O_DSYNC O_FSYNC
+#endif
+#endif
+
+/* Approximate O_DIRECT with O_DSYNC if O_DIRECT isn't available */
+#ifndef O_DIRECT
+#define O_DIRECT O_DSYNC
+#endif
+
 enum {
     VHOST_USER_BLK_MAX_QUEUES = 8,
 };
@@ -267,13 +282,13 @@ static int vub_virtio_process_req(VubDev *vdev_blk,
     req->in = (struct virtio_blk_inhdr *)elem->in_sg[in_num - 1].iov_base;
     in_num--;
 
-    type = le32toh(req->out->type);
+    type = le32_to_cpu(req->out->type);
     switch (type & ~VIRTIO_BLK_T_BARRIER) {
     case VIRTIO_BLK_T_IN:
     case VIRTIO_BLK_T_OUT: {
         ssize_t ret = 0;
         bool is_write = type & VIRTIO_BLK_T_OUT;
-        req->sector_num = le64toh(req->out->sector);
+        req->sector_num = le64_to_cpu(req->out->sector);
         if (is_write) {
             ret  = vub_writev(req, &elem->out_sg[1], out_num);
         } else {
diff --git a/util/meson.build b/util/meson.build
index 0ef9886be0..f52682ce96 100644
--- a/util/meson.build
+++ b/util/meson.build
@@ -113,10 +113,12 @@ if have_block
     util_ss.add(files('filemonitor-stub.c'))
   endif
   if host_os == 'linux'
-    util_ss.add(files('vhost-user-server.c'), vhost_user)
     util_ss.add(files('vfio-helpers.c'))
     util_ss.add(files('chardev_open.c'))
   endif
+  if host_os != 'windows'
+    util_ss.add(files('vhost-user-server.c'), vhost_user)
+  endif
 endif
 
 if cpu == 'aarch64'
-- 
2.43.2

[PATCH 9/9] hostmem-file: support POSIX shm_open()

[Stefano Garzarella]

Add a new `shm` bool option for `-object memory-backend-file`.

When this option is set to true, the POSIX shm_open(3) is used instead
of open(2).

So a file will not be created in the filesystem, but a "POSIX shared
memory object" will be instantiated. In Linux this turns into a file
in /dev/shm, but in other OSes this may not happen (for example in
macOS or FreeBSD nothing is shown in any filesystem).

This new feature is useful when we need to share guest memory with
another process (e.g. vhost-user backend), but we don't have
memfd_create() or any special filesystems (e.g. /dev/shm) available
as in macOS.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
I am not sure this is the best way to support shm_open() in QEMU.

Other solutions I had in mind were:

- create a new memory-backend-shm

- extend memory-backend-memfd to use shm_open() on systems where memfd is
not available (problem: shm_open wants a name to assign to the object, but
we can do a workaround by using a random name and do the unlink right away)

Any preference/suggestion?

Thanks,
Stefano
---
 qapi/qom.json           |  4 +++
 backends/hostmem-file.c | 57 ++++++++++++++++++++++++++++++++++++++++-
 backends/meson.build    |  2 +-
 qemu-options.hx         | 10 +++++++-
 4 files changed, 70 insertions(+), 3 deletions(-)

diff --git a/qapi/qom.json b/qapi/qom.json
index 2a6e49365a..bfb01b909f 100644
--- a/qapi/qom.json
+++ b/qapi/qom.json
@@ -682,6 +682,9 @@
 #       writable RAM instead of ROM, and want to set this property to 'off'.
 #       (default: auto, since 8.2)
 #
+# @shm: if true, shm_open(3) is used to create/open POSIX shared memory
+#       object; if false, an open(2) is used. (default: false) (since 9.0)
+#
 # Since: 2.1
 ##
 { 'struct': 'MemoryBackendFileProperties',
@@ -692,6 +695,7 @@
             'mem-path': 'str',
             '*pmem': { 'type': 'bool', 'if': 'CONFIG_LIBPMEM' },
             '*readonly': 'bool',
+            '*shm': 'bool',
             '*rom': 'OnOffAuto' } }
 
 ##
diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index ac3e433cbd..9d60375c1f 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -34,6 +34,7 @@ struct HostMemoryBackendFile {
     bool is_pmem;
     bool readonly;
     OnOffAuto rom;
+    bool shm;
 };
 
 static bool
@@ -86,7 +87,37 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
     ram_flags |= fb->rom == ON_OFF_AUTO_ON ? RAM_READONLY : 0;
     ram_flags |= backend->reserve ? 0 : RAM_NORESERVE;
     ram_flags |= fb->is_pmem ? RAM_PMEM : 0;
+    /* TODO: check if this should be enabled if shm is enabled */
     ram_flags |= RAM_NAMED_FILE;
+
+    if (fb->shm) {
+        mode_t mode = S_IRUSR | S_IWUSR;
+        int fd, oflag = 0;
+
+        oflag |= fb->readonly ? O_RDONLY : O_RDWR;
+        oflag |= O_CREAT;
+
+        fd = shm_open(fb->mem_path, oflag, mode);
+        if (fd < 0) {
+            error_setg_errno(errp, errno,
+                             "failed to create POSIX shared memory");
+            return false;
+        }
+
+        if (ftruncate(fd, backend->size) == -1) {
+            error_setg_errno(errp, errno,
+                             "failed to resize POSIX shared memory to %" PRIu64,
+                             backend->size);
+            shm_unlink(fb->mem_path);
+            return false;
+        }
+
+        return memory_region_init_ram_from_fd(&backend->mr, OBJECT(backend),
+                                              name, backend->size, ram_flags,
+                                              fd, fb->offset, errp);
+
+    }
+
     return memory_region_init_ram_from_file(&backend->mr, OBJECT(backend), name,
                                             backend->size, fb->align, ram_flags,
                                             fb->mem_path, fb->offset, errp);
@@ -254,17 +285,36 @@ static void file_memory_backend_set_rom(Object *obj, Visitor *v,
     visit_type_OnOffAuto(v, name, &fb->rom, errp);
 }
 
+static bool file_memory_backend_get_shm(Object *obj, Error **errp)
+{
+    return MEMORY_BACKEND_FILE(obj)->shm;
+}
+
+static void file_memory_backend_set_shm(Object *obj, bool value,
+                                             Error **errp)
+{
+    MEMORY_BACKEND_FILE(obj)->shm = value;
+}
+
 static void file_backend_unparent(Object *obj)
 {
     HostMemoryBackend *backend = MEMORY_BACKEND(obj);
     HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(obj);
 
-    if (host_memory_backend_mr_inited(backend) && fb->discard_data) {
+    if (!host_memory_backend_mr_inited(backend)) {
+        return;
+    }
+
+    if (fb->discard_data) {
         void *ptr = memory_region_get_ram_ptr(&backend->mr);
         uint64_t sz = memory_region_size(&backend->mr);
 
         qemu_madvise(ptr, sz, QEMU_MADV_REMOVE);
     }
+
+    if (fb->shm) {
+        shm_unlink(fb->mem_path);
+    }
 }
 
 static void
@@ -300,6 +350,11 @@ file_backend_class_init(ObjectClass *oc, void *data)
         file_memory_backend_get_rom, file_memory_backend_set_rom, NULL, NULL);
     object_class_property_set_description(oc, "rom",
         "Whether to create Read Only Memory (ROM)");
+    object_class_property_add_bool(oc, "shm",
+        file_memory_backend_get_shm,
+        file_memory_backend_set_shm);
+    object_class_property_set_description(oc, "shm",
+        "Use shm_open(3) to create/open POSIX shared memory objects");
 }
 
 static void file_backend_instance_finalize(Object *o)
diff --git a/backends/meson.build b/backends/meson.build
index 8b2b111497..64520c0a7e 100644
--- a/backends/meson.build
+++ b/backends/meson.build
@@ -12,7 +12,7 @@ system_ss.add([files(
 
 if host_os != 'windows'
   system_ss.add(files('rng-random.c'))
-  system_ss.add(files('hostmem-file.c'))
+  system_ss.add([files('hostmem-file.c'), rt])
 endif
 if host_os == 'linux'
   system_ss.add(files('hostmem-memfd.c'))
diff --git a/qemu-options.hx b/qemu-options.hx
index 9be1e5817c..da96ee506d 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -5079,7 +5079,7 @@ SRST
     they are specified. Note that the 'id' property must be set. These
     objects are placed in the '/objects' path.
 
-    ``-object memory-backend-file,id=id,size=size,mem-path=dir,share=on|off,discard-data=on|off,merge=on|off,dump=on|off,prealloc=on|off,host-nodes=host-nodes,policy=default|preferred|bind|interleave,align=align,offset=offset,readonly=on|off,rom=on|off|auto``
+    ``-object memory-backend-file,id=id,size=size,mem-path=dir,share=on|off,discard-data=on|off,merge=on|off,dump=on|off,prealloc=on|off,host-nodes=host-nodes,policy=default|preferred|bind|interleave,align=align,offset=offset,readonly=on|off,rom=on|off|auto,shm=on|off``
         Creates a memory file backend object, which can be used to back
         the guest RAM with huge pages.
 
@@ -5183,6 +5183,14 @@ SRST
         (``share=off``). For this use case, we need writable RAM instead
         of ROM, and want to also set ``rom=off``.
 
+        The ``shm`` option specifies whether to create/open a POSIX shared
+        memory object identified by ``mem-path``.
+        If set to ``on``, use shm_open(3); if set to ``off`` (default),
+        use open(2); For portable use, a shared memory object should be
+        identified by a name of the form ``/somename``; consisting of an
+        initial slash, followed by one or more characters, none of which
+        are slashes.
+
     ``-object memory-backend-ram,id=id,merge=on|off,dump=on|off,share=on|off,prealloc=on|off,size=size,host-nodes=host-nodes,policy=default|preferred|bind|interleave``
         Creates a memory backend object, which can be used to back the
         guest RAM. Memory backend objects offer more control than the
-- 
2.43.2

Re: [PATCH 0/9] vhost-user: support any POSIX system (tested on macOS and FreeBSD)

[Stefano Garzarella]

I just noticed that I forgot to add RFC tag and fix Author to match
SOB in some patches, sorry!

Stefano

On Wed, Feb 28, 2024 at 12:48 PM Stefano Garzarella <sgarzare@redhat.com> wrote:
>
> The vhost-user protocol is not really Linux-specific, so let's try support
> QEMU's frontends and backends (including libvhost-user) in any POSIX system
> with this series. The main use case is to be able to use virtio devices that
> we don't have built-in in QEMU (e.g. virtiofsd, vhost-user-vsock, etc.) even
> in non-Linux systems.
>
> The first 5 patches are more like fixes discovered at runtime on macOS or
> FreeBSD that could go even independently of this series.
>
> Patches 6, 7, and 8 enable building of frontends and backends (including
> libvhost-user) with associated code changes to succeed in compilation.
>
> The latest patch (9) adds support for the POSIX shm_open() API to create
> shared memory which is identified by an fd that can be shared with vhost-user
> backends. This is useful on those systems (like macOS) where we don't have
> memfd_create() or special filesystems like "/dev/shm".
>
> I put the whole series in RFC because I have some questions especially in
> patch 6 and 9, but in general any comment/suggestion/test are really welcome.
>
> Maybe the first 5 patches can go separately, but I only discovered those
> problems after testing patches 6 - 9, so I have included them in this series
> for now. Please let me know if you prefer that I send them separately.
>
> For now I tested this series using vhost-user-blk and QSD on
> macOS Sonoma 14.3.1 (aarch64), FreeBSD 14 (x86_64), and Fedora 39 (x86_64)
> in this way:
>
> - Start vhost-user-blk or QSD (same commands for all systems)
>
>   vhost-user-blk -s /tmp/vhost.socket \
>     -b Fedora-Cloud-Base-39-1.5.x86_64.raw
>
>   qemu-storage-daemon \
>     --blockdev file,filename=Fedora-Cloud-Base-39-1.5.x86_64.qcow2,node-name=file \
>     --blockdev qcow2,file=file,node-name=qcow2 \
>     --export vhost-user-blk,addr.type=unix,addr.path=/tmp/vhost.socket,id=vub,num-queues=1,node-name=qcow2,writable=on
>
> - macOS (aarch64): start QEMU (using hvf accelerator)
>
>   qemu-system-aarch64 -smp 2 -cpu host -M virt,accel=hvf,memory-backend=mem \
>     -drive file=./build/pc-bios/edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on \
>     -device virtio-net-device,netdev=net0 -netdev user,id=net0 \
>     -device ramfb -device usb-ehci -device usb-kbd \
>     -object memory-backend-file,mem-path="/mem0",shm=on,share=on,id=mem,size=512M \
>     -device vhost-user-blk-pci,num-queues=1,disable-legacy=on,chardev=char0 \
>     -chardev socket,id=char0,path=/tmp/vhost.socket
>
> - FreeBSD (x86_64): start QEMU (no accelerators available)
>
>   qemu-system-x86_64 -smp 2 -M q35,memory-backend=mem \
>     -object memory-backend-file,mem-path="/mem0",shm=on,share=on,id=mem,size="512M" \
>     -device vhost-user-blk-pci,num-queues=1,chardev=char0 \
>     -chardev socket,id=char0,path=/tmp/vhost.socket
>
> - Fedora (x86_64): start QEMU (using kvm accelerator)
>
>   qemu-system-x86_64 -smp 2 -M q35,accel=kvm,memory-backend=mem \
>     -object memory-backend-file,mem-path="/mem0",shm=on,share=on,id=mem,size="512M" \
>     -device vhost-user-blk-pci,num-queues=1,chardev=char0 \
>     -chardev socket,id=char0,path=/tmp/vhost.socket
>
> Thanks,
> Stefano
>
> Stefano Garzarella (9):
>   libvhost-user: set msg.msg_control to NULL when it is empty
>   libvhost-user: fail vu_message_write() if sendmsg() is failing
>   libvhost-user: mask F_INFLIGHT_SHMFD if memfd is not supported
>   vhost-user-server: don't abort if we can't set fd non-blocking
>   contrib/vhost-user-blk: fix bind() using the right size of the address
>   vhost-user: enable frontends on any POSIX system
>   libvhost-user: enable it on any POSIX system
>   contrib/vhost-user-blk: enabled it on any POSIX system
>   hostmem-file: support POSIX shm_open()
>
>  meson.build                               |  5 +-
>  qapi/qom.json                             |  4 ++
>  subprojects/libvhost-user/libvhost-user.h |  2 +-
>  backends/hostmem-file.c                   | 57 ++++++++++++++++-
>  contrib/vhost-user-blk/vhost-user-blk.c   | 23 +++++--
>  hw/net/vhost_net.c                        |  8 ++-
>  subprojects/libvhost-user/libvhost-user.c | 76 ++++++++++++++++++++++-
>  util/vhost-user-server.c                  |  6 +-
>  backends/meson.build                      |  2 +-
>  hw/block/Kconfig                          |  2 +-
>  qemu-options.hx                           | 10 ++-
>  util/meson.build                          |  4 +-
>  12 files changed, 179 insertions(+), 20 deletions(-)
>
> --
> 2.43.2
>

Re: [PATCH 9/9] hostmem-file: support POSIX shm_open()

[David Hildenbrand]

On 28.02.24 12:47, Stefano Garzarella wrote:
> Add a new `shm` bool option for `-object memory-backend-file`.
> 
> When this option is set to true, the POSIX shm_open(3) is used instead
> of open(2).
> 
> So a file will not be created in the filesystem, but a "POSIX shared
> memory object" will be instantiated. In Linux this turns into a file
> in /dev/shm, but in other OSes this may not happen (for example in
> macOS or FreeBSD nothing is shown in any filesystem).
> 
> This new feature is useful when we need to share guest memory with
> another process (e.g. vhost-user backend), but we don't have
> memfd_create() or any special filesystems (e.g. /dev/shm) available
> as in macOS.
> 
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> I am not sure this is the best way to support shm_open() in QEMU.
> 
> Other solutions I had in mind were:
> 
> - create a new memory-backend-shm
> 
> - extend memory-backend-memfd to use shm_open() on systems where memfd is
> not available (problem: shm_open wants a name to assign to the object, but
> we can do a workaround by using a random name and do the unlink right away)
> 
> Any preference/suggestion?

Both sound like reasonable options, and IMHO better than hostmem-file 
with things that are not necessarily "real" files.

Regarding memory-backend-memfd, we similarly have to pass a name to 
memfd_create(), although for different purpose: "The  name  supplied in 
name is used as a filename and will be displayed as the target of the 
corresponding symbolic link in the directory /proc/self/fd/".

So we simply pass TYPE_MEMORY_BACKEND_MEMFD.

Likely, memory-backend-shm that directly maps to shm_open() and only 
provides properties reasonable for shm_open() is the cleanest approach. 
So that would currently be my preference :)

-- 
Cheers,

David / dhildenb

Re: [PATCH 9/9] hostmem-file: support POSIX shm_open()

[Daniel P. Berrangé]

On Wed, Feb 28, 2024 at 12:47:59PM +0100, Stefano Garzarella wrote:
> Add a new `shm` bool option for `-object memory-backend-file`.
> 
> When this option is set to true, the POSIX shm_open(3) is used instead
> of open(2).
> 
> So a file will not be created in the filesystem, but a "POSIX shared
> memory object" will be instantiated. In Linux this turns into a file
> in /dev/shm, but in other OSes this may not happen (for example in
> macOS or FreeBSD nothing is shown in any filesystem).
> 
> This new feature is useful when we need to share guest memory with
> another process (e.g. vhost-user backend), but we don't have
> memfd_create() or any special filesystems (e.g. /dev/shm) available
> as in macOS.
> 
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> I am not sure this is the best way to support shm_open() in QEMU.
> 
> Other solutions I had in mind were:
> 
> - create a new memory-backend-shm
> 
> - extend memory-backend-memfd to use shm_open() on systems where memfd is
> not available (problem: shm_open wants a name to assign to the object, but
> we can do a workaround by using a random name and do the unlink right away)

IMHO, create a new memory-backend-shm, don't overload memory-backend-memfd,
as this lets users choose between shm & memfd, even on Linux.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH 9/9] hostmem-file: support POSIX shm_open()

[Markus Armbruster]

Stefano Garzarella <sgarzare@redhat.com> writes:

> Add a new `shm` bool option for `-object memory-backend-file`.
>
> When this option is set to true, the POSIX shm_open(3) is used instead
> of open(2).
>
> So a file will not be created in the filesystem, but a "POSIX shared
> memory object" will be instantiated. In Linux this turns into a file
> in /dev/shm, but in other OSes this may not happen (for example in
> macOS or FreeBSD nothing is shown in any filesystem).
>
> This new feature is useful when we need to share guest memory with
> another process (e.g. vhost-user backend), but we don't have
> memfd_create() or any special filesystems (e.g. /dev/shm) available
> as in macOS.
>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> I am not sure this is the best way to support shm_open() in QEMU.
>
> Other solutions I had in mind were:
>
> - create a new memory-backend-shm

How would that look like?  Would it involve duplicating code?

> - extend memory-backend-memfd to use shm_open() on systems where memfd is
> not available (problem: shm_open wants a name to assign to the object, but
> we can do a workaround by using a random name and do the unlink right away)

Hmm.  Too much magic?  I don't know...

> Any preference/suggestion?

[...]

> diff --git a/qapi/qom.json b/qapi/qom.json
> index 2a6e49365a..bfb01b909f 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -682,6 +682,9 @@
   # @mem-path: the path to either a shared memory or huge page
   #     filesystem mount

Does this need adjustment?

[...]

>  #       writable RAM instead of ROM, and want to set this property to 'off'.
>  #       (default: auto, since 8.2)
>  #
> +# @shm: if true, shm_open(3) is used to create/open POSIX shared memory
> +#       object; if false, an open(2) is used. (default: false) (since 9.0)
> +#

Please format like this for consistency:

# @shm: if true, shm_open(3) is used to create/open POSIX shared memory
#     object; if false, an open(2) is used (default: false) (since 9.0)

>  # Since: 2.1
>  ##
>  { 'struct': 'MemoryBackendFileProperties',
> @@ -692,6 +695,7 @@
>              'mem-path': 'str',
>              '*pmem': { 'type': 'bool', 'if': 'CONFIG_LIBPMEM' },
>              '*readonly': 'bool',
> +            '*shm': 'bool',
>              '*rom': 'OnOffAuto' } }
>  
>  ##

[...]

Re: [PATCH 9/9] hostmem-file: support POSIX shm_open()

[Stefano Garzarella]

On Wed, Feb 28, 2024 at 01:01:55PM +0100, David Hildenbrand wrote:
>On 28.02.24 12:47, Stefano Garzarella wrote:
>>Add a new `shm` bool option for `-object memory-backend-file`.
>>
>>When this option is set to true, the POSIX shm_open(3) is used instead
>>of open(2).
>>
>>So a file will not be created in the filesystem, but a "POSIX shared
>>memory object" will be instantiated. In Linux this turns into a file
>>in /dev/shm, but in other OSes this may not happen (for example in
>>macOS or FreeBSD nothing is shown in any filesystem).
>>
>>This new feature is useful when we need to share guest memory with
>>another process (e.g. vhost-user backend), but we don't have
>>memfd_create() or any special filesystems (e.g. /dev/shm) available
>>as in macOS.
>>
>>Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
>>---
>>I am not sure this is the best way to support shm_open() in QEMU.
>>
>>Other solutions I had in mind were:
>>
>>- create a new memory-backend-shm
>>
>>- extend memory-backend-memfd to use shm_open() on systems where memfd is
>>not available (problem: shm_open wants a name to assign to the object, but
>>we can do a workaround by using a random name and do the unlink right away)
>>
>>Any preference/suggestion?
>
>Both sound like reasonable options, and IMHO better than hostmem-file 
>with things that are not necessarily "real" files.

Yeah, I see.

>
>Regarding memory-backend-memfd, we similarly have to pass a name to 
>memfd_create(), although for different purpose: "The  name  supplied 
>in name is used as a filename and will be displayed as the target of 
>the corresponding symbolic link in the directory /proc/self/fd/".
>
>So we simply pass TYPE_MEMORY_BACKEND_MEMFD.

Okay, so I guess it must be unique only in the process, while for 
shm_open() it is global.

>
>Likely, memory-backend-shm that directly maps to shm_open() and only 
>provides properties reasonable for shm_open() is the cleanest 
>approach. So that would currently be my preference :)

Thank you for your thoughts, I think I will go toward this direction 
(memory-backend-shm).

It was also my first choice, but in order to have a working RFC right 
away, I modified memory-backend-file.

Stefano

Re: [PATCH 9/9] hostmem-file: support POSIX shm_open()

[Stefano Garzarella]

On Wed, Feb 28, 2024 at 12:08:37PM +0000, Daniel P. Berrangé wrote:
>On Wed, Feb 28, 2024 at 12:47:59PM +0100, Stefano Garzarella wrote:
>> Add a new `shm` bool option for `-object memory-backend-file`.
>>
>> When this option is set to true, the POSIX shm_open(3) is used instead
>> of open(2).
>>
>> So a file will not be created in the filesystem, but a "POSIX shared
>> memory object" will be instantiated. In Linux this turns into a file
>> in /dev/shm, but in other OSes this may not happen (for example in
>> macOS or FreeBSD nothing is shown in any filesystem).
>>
>> This new feature is useful when we need to share guest memory with
>> another process (e.g. vhost-user backend), but we don't have
>> memfd_create() or any special filesystems (e.g. /dev/shm) available
>> as in macOS.
>>
>> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
>> ---
>> I am not sure this is the best way to support shm_open() in QEMU.
>>
>> Other solutions I had in mind were:
>>
>> - create a new memory-backend-shm
>>
>> - extend memory-backend-memfd to use shm_open() on systems where memfd is
>> not available (problem: shm_open wants a name to assign to the object, but
>> we can do a workaround by using a random name and do the unlink right away)
>
>IMHO, create a new memory-backend-shm, don't overload memory-backend-memfd,
>as this lets users choose between shm & memfd, even on Linux.

Yeah, good point!
I think there's enough of a consensus on adding memory-backend-shm, so 
I'm going to go toward that direction in v2.

Thanks,
Stefano

Re: [PATCH 9/9] hostmem-file: support POSIX shm_open()

[Stefano Garzarella]

On Wed, Feb 28, 2024 at 01:32:17PM +0100, Markus Armbruster wrote:
>Stefano Garzarella <sgarzare@redhat.com> writes:
>
>> Add a new `shm` bool option for `-object memory-backend-file`.
>>
>> When this option is set to true, the POSIX shm_open(3) is used instead
>> of open(2).
>>
>> So a file will not be created in the filesystem, but a "POSIX shared
>> memory object" will be instantiated. In Linux this turns into a file
>> in /dev/shm, but in other OSes this may not happen (for example in
>> macOS or FreeBSD nothing is shown in any filesystem).
>>
>> This new feature is useful when we need to share guest memory with
>> another process (e.g. vhost-user backend), but we don't have
>> memfd_create() or any special filesystems (e.g. /dev/shm) available
>> as in macOS.
>>
>> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
>> ---
>> I am not sure this is the best way to support shm_open() in QEMU.
>>
>> Other solutions I had in mind were:
>>
>> - create a new memory-backend-shm
>
>How would that look like?  Would it involve duplicating code?

I was looking at it just now, and apart from some boilerplate code to 
create the object, the rest in the end is pretty specific and a lot of 
things in memory-backend-file wouldn't be supported by 
memory-backend-shm anyway, so I'll give it a try for v2 by adding it.

>
>> - extend memory-backend-memfd to use shm_open() on systems where memfd is
>> not available (problem: shm_open wants a name to assign to the object, but
>> we can do a workaround by using a random name and do the unlink right away)
>
>Hmm.  Too much magic?  I don't know...

Yeah, I agree.

>
>> Any preference/suggestion?
>
>[...]
>
>> diff --git a/qapi/qom.json b/qapi/qom.json
>> index 2a6e49365a..bfb01b909f 100644
>> --- a/qapi/qom.json
>> +++ b/qapi/qom.json
>> @@ -682,6 +682,9 @@
>   # @mem-path: the path to either a shared memory or huge page
>   #     filesystem mount
>
>Does this need adjustment?

Good point. For now I think I will drop this patch and add 
memory-backend-shm in v2, but if I go back I will fix it!

>
>[...]
>
>>  #       writable RAM instead of ROM, and want to set this property to 'off'.
>>  #       (default: auto, since 8.2)
>>  #
>> +# @shm: if true, shm_open(3) is used to create/open POSIX shared memory
>> +#       object; if false, an open(2) is used. (default: false) (since 9.0)
>> +#
>
>Please format like this for consistency:

Sure.

>
># @shm: if true, shm_open(3) is used to create/open POSIX shared memory
>#     object; if false, an open(2) is used (default: false) (since 9.0)

I just noticed that I followed the property just above (@rom). Should we 
fix that one?

Thanks,
Stefano

Re: [PATCH 9/9] hostmem-file: support POSIX shm_open()

[Markus Armbruster]

Stefano Garzarella <sgarzare@redhat.com> writes:

> On Wed, Feb 28, 2024 at 01:32:17PM +0100, Markus Armbruster wrote:
>>Stefano Garzarella <sgarzare@redhat.com> writes:

[...]

>>> +# @shm: if true, shm_open(3) is used to create/open POSIX shared memory
>>> +#       object; if false, an open(2) is used. (default: false) (since 9.0)
>>> +#
>>
>>Please format like this for consistency:
>
> Sure.
>
>>
>># @shm: if true, shm_open(3) is used to create/open POSIX shared memory
>>#     object; if false, an open(2) is used (default: false) (since 9.0)
>
> I just noticed that I followed the property just above (@rom). Should we fix that one?

Yes, please.

See commit a937b6aa739 (qapi: Reformat doc comments to conform to
current conventions).

Re: [PATCH 9/9] hostmem-file: support POSIX shm_open()

[Stefano Garzarella]

On Thu, Feb 29, 2024 at 11:28:37AM +0100, Markus Armbruster wrote:
>Stefano Garzarella <sgarzare@redhat.com> writes:
>
>> On Wed, Feb 28, 2024 at 01:32:17PM +0100, Markus Armbruster wrote:
>>>Stefano Garzarella <sgarzare@redhat.com> writes:
>
>[...]
>
>>>> +# @shm: if true, shm_open(3) is used to create/open POSIX shared memory
>>>> +#       object; if false, an open(2) is used. (default: false) (since 9.0)
>>>> +#
>>>
>>>Please format like this for consistency:
>>
>> Sure.
>>
>>>
>>># @shm: if true, shm_open(3) is used to create/open POSIX shared memory
>>>#     object; if false, an open(2) is used (default: false) (since 9.0)
>>
>> I just noticed that I followed the property just above (@rom). Should we fix that one?
>
>Yes, please.

Done: 
https://patchew.org/QEMU/20240229105826.16354-1-sgarzare@redhat.com/

Thanks,
Stefano

>
>See commit a937b6aa739 (qapi: Reformat doc comments to conform to
>current conventions).
>