From 233982af53915bd9fbfa604e3b566b50af6fe5a7 Mon Sep 17 00:00:00 2001 From: Christian Schoenebeck Date: Thu, 14 May 2020 08:06:43 +0200 Subject: [PATCH 1/4] MAINTAINERS: Upgrade myself as 9pfs co-maintainer MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As suggested by Greg, let's upgrade myself as co-maintainer of 9pfs. Signed-off-by: Christian Schoenebeck Reviewed-by: Philippe Mathieu-Daudé Message-Id: Signed-off-by: Greg Kurz --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1f84e3ae2c..005ee98a59 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1657,7 +1657,7 @@ F: include/sysemu/balloon.h virtio-9p M: Greg Kurz -R: Christian Schoenebeck +M: Christian Schoenebeck S: Odd Fixes F: hw/9pfs/ X: hw/9pfs/xen-9p* From 65abaa01ee5781f525e1b9a0d6e6e5a3d8696d5f Mon Sep 17 00:00:00 2001 From: Christian Schoenebeck Date: Thu, 14 May 2020 08:06:43 +0200 Subject: [PATCH 2/4] qemu-options.hx: 9p: clarify -virtfs vs. -fsdev The docs are ambiguous about the difference (or actually their equality) between options '-virtfs' vs. '-fsdev'. So clarify that '-virtfs' is actually just a convenience shortcut for its generalized form '-fsdev' in conjunction with '-device virtio-9p-pci'. And as we're at it, also be a bit more descriptive what 9pfs is actually used for. Signed-off-by: Christian Schoenebeck Acked-by: Cornelia Huck Message-Id: <208f1fceffce2feaf7c900b29e326b967dce7762.1585661532.git.qemu_oss@crudebyte.com> Signed-off-by: Greg Kurz --- qemu-options.hx | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/qemu-options.hx b/qemu-options.hx index 292d4e7c0c..e2dca8a4e9 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -1542,9 +1542,17 @@ SRST ``-virtfs proxy,sock_fd=sock_fd,mount_tag=mount_tag [,writeout=writeout][,readonly]`` \ ``-virtfs synth,mount_tag=mount_tag`` - Define a new filesystem device and expose it to the guest using a - virtio-9p-device. The general form of a Virtual File system - pass-through options are: + Define a new virtual filesystem device and expose it to the guest using + a virtio-9p-device (a.k.a. 9pfs), which essentially means that a certain + directory on host is made directly accessible by guest as a pass-through + file system by using the 9P network protocol for communication between + host and guests, if desired even accessible, shared by several guests + simultaniously. + + Note that ``-virtfs`` is actually just a convenience shortcut for its + generalized form ``-fsdev -device virtio-9p-pci``. + + The general form of pass-through file system options are: ``local`` Accesses to the filesystem are done by QEMU. From a5804fcf7b22fc7d1f9ec794dd284c7d504bd16b Mon Sep 17 00:00:00 2001 From: Omar Sandoval Date: Thu, 14 May 2020 08:06:43 +0200 Subject: [PATCH 3/4] 9pfs: local: ignore O_NOATIME if we don't have permissions QEMU's local 9pfs server passes through O_NOATIME from the client. If the QEMU process doesn't have permissions to use O_NOATIME (namely, it does not own the file nor have the CAP_FOWNER capability), the open will fail. This causes issues when from the client's point of view, it believes it has permissions to use O_NOATIME (e.g., a process running as root in the virtual machine). Additionally, overlayfs on Linux opens files on the lower layer using O_NOATIME, so in this case a 9pfs mount can't be used as a lower layer for overlayfs (cf. https://github.com/osandov/drgn/blob/dabfe1971951701da13863dbe6d8a1d172ad9650/vmtest/onoatimehack.c and https://github.com/NixOS/nixpkgs/issues/54509). Luckily, O_NOATIME is effectively a hint, and is often ignored by, e.g., network filesystems. open(2) notes that O_NOATIME "may not be effective on all filesystems. One example is NFS, where the server maintains the access time." This means that we can honor it when possible but fall back to ignoring it. Acked-by: Christian Schoenebeck Signed-off-by: Omar Sandoval Message-Id: Signed-off-by: Greg Kurz --- hw/9pfs/9p-util.h | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h index 79ed6b233e..546f46dc7d 100644 --- a/hw/9pfs/9p-util.h +++ b/hw/9pfs/9p-util.h @@ -37,9 +37,22 @@ static inline int openat_file(int dirfd, const char *name, int flags, { int fd, serrno, ret; +again: fd = openat(dirfd, name, flags | O_NOFOLLOW | O_NOCTTY | O_NONBLOCK, mode); if (fd == -1) { + if (errno == EPERM && (flags & O_NOATIME)) { + /* + * The client passed O_NOATIME but we lack permissions to honor it. + * Rather than failing the open, fall back without O_NOATIME. This + * doesn't break the semantics on the client side, as the Linux + * open(2) man page notes that O_NOATIME "may not be effective on + * all filesystems". In particular, NFS and other network + * filesystems ignore it entirely. + */ + flags &= ~O_NOATIME; + goto again; + } return -1; } From 9bbb7e0fe081efff2e41f8517c256b72a284fe9b Mon Sep 17 00:00:00 2001 From: Christian Schoenebeck Date: Thu, 14 May 2020 08:06:43 +0200 Subject: [PATCH 4/4] xen-9pfs: Fix log messages of reply errors If delivery of some 9pfs response fails for some reason, log the error message by mentioning the 9P protocol reply type, not by client's request type. The latter could be misleading that the error occurred already when handling the request input. Signed-off-by: Christian Schoenebeck Acked-by: Stefano Stabellini Message-Id: Signed-off-by: Greg Kurz --- hw/9pfs/xen-9p-backend.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c index 18fe5b7c92..f04caabfe5 100644 --- a/hw/9pfs/xen-9p-backend.c +++ b/hw/9pfs/xen-9p-backend.c @@ -137,7 +137,8 @@ static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu, ret = v9fs_iov_vmarshal(in_sg, num, offset, 0, fmt, ap); if (ret < 0) { xen_pv_printf(&xen_9pfs->xendev, 0, - "Failed to encode VirtFS request type %d\n", pdu->id + 1); + "Failed to encode VirtFS reply type %d\n", + pdu->id + 1); xen_be_set_state(&xen_9pfs->xendev, XenbusStateClosing); xen_9pfs_disconnect(&xen_9pfs->xendev); } @@ -201,9 +202,9 @@ static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu, buf_size = iov_size(ring->sg, num); if (buf_size < P9_IOHDRSZ) { - xen_pv_printf(&xen_9pfs->xendev, 0, "Xen 9pfs request type %d" - "needs %zu bytes, buffer has %zu, less than minimum\n", - pdu->id, *size, buf_size); + xen_pv_printf(&xen_9pfs->xendev, 0, "Xen 9pfs reply type %d needs " + "%zu bytes, buffer has %zu, less than minimum\n", + pdu->id + 1, *size, buf_size); xen_be_set_state(&xen_9pfs->xendev, XenbusStateClosing); xen_9pfs_disconnect(&xen_9pfs->xendev); }