* [PULL 1/4] MAINTAINERS: Upgrade myself as 9pfs co-maintainer
2020-05-14 9:05 [PULL 0/4] 9p patches 2020-05-14 Greg Kurz
@ 2020-05-14 9:05 ` Greg Kurz
2020-05-14 9:05 ` [PULL 2/4] qemu-options.hx: 9p: clarify -virtfs vs. -fsdev Greg Kurz
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Greg Kurz @ 2020-05-14 9:05 UTC (permalink / raw)
To: qemu-devel, Peter Maydell
Cc: Philippe Mathieu-Daudé, Christian Schoenebeck, Greg Kurz
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
As suggested by Greg, let's upgrade myself as co-maintainer of 9pfs.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <E1jEYz4-0004pt-Cs@lizzy.crudebyte.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1f84e3ae2c6a..005ee98a59f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1657,7 +1657,7 @@ F: include/sysemu/balloon.h
virtio-9p
M: Greg Kurz <groug@kaod.org>
-R: Christian Schoenebeck <qemu_oss@crudebyte.com>
+M: Christian Schoenebeck <qemu_oss@crudebyte.com>
S: Odd Fixes
F: hw/9pfs/
X: hw/9pfs/xen-9p*
--
2.21.3
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PULL 2/4] qemu-options.hx: 9p: clarify -virtfs vs. -fsdev
2020-05-14 9:05 [PULL 0/4] 9p patches 2020-05-14 Greg Kurz
2020-05-14 9:05 ` [PULL 1/4] MAINTAINERS: Upgrade myself as 9pfs co-maintainer Greg Kurz
@ 2020-05-14 9:05 ` Greg Kurz
2020-05-14 9:05 ` [PULL 3/4] 9pfs: local: ignore O_NOATIME if we don't have permissions Greg Kurz
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Greg Kurz @ 2020-05-14 9:05 UTC (permalink / raw)
To: qemu-devel, Peter Maydell; +Cc: Cornelia Huck, Christian Schoenebeck, Greg Kurz
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
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 <qemu_oss@crudebyte.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <208f1fceffce2feaf7c900b29e326b967dce7762.1585661532.git.qemu_oss@crudebyte.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
---
qemu-options.hx | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 292d4e7c0cef..e2dca8a4e96b 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.
--
2.21.3
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PULL 3/4] 9pfs: local: ignore O_NOATIME if we don't have permissions
2020-05-14 9:05 [PULL 0/4] 9p patches 2020-05-14 Greg Kurz
2020-05-14 9:05 ` [PULL 1/4] MAINTAINERS: Upgrade myself as 9pfs co-maintainer Greg Kurz
2020-05-14 9:05 ` [PULL 2/4] qemu-options.hx: 9p: clarify -virtfs vs. -fsdev Greg Kurz
@ 2020-05-14 9:05 ` Greg Kurz
2020-05-14 9:05 ` [PULL 4/4] xen-9pfs: Fix log messages of reply errors Greg Kurz
2020-05-14 10:49 ` [PULL 0/4] 9p patches 2020-05-14 Peter Maydell
4 siblings, 0 replies; 6+ messages in thread
From: Greg Kurz @ 2020-05-14 9:05 UTC (permalink / raw)
To: qemu-devel, Peter Maydell; +Cc: Christian Schoenebeck, Greg Kurz, Omar Sandoval
From: Omar Sandoval <osandov@fb.com>
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 <qemu_oss@crudebyte.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Message-Id: <e9bee604e8df528584693a4ec474ded6295ce8ad.1587149256.git.osandov@fb.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
---
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 79ed6b233e58..546f46dc7dc6 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;
}
--
2.21.3
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PULL 4/4] xen-9pfs: Fix log messages of reply errors
2020-05-14 9:05 [PULL 0/4] 9p patches 2020-05-14 Greg Kurz
` (2 preceding siblings ...)
2020-05-14 9:05 ` [PULL 3/4] 9pfs: local: ignore O_NOATIME if we don't have permissions Greg Kurz
@ 2020-05-14 9:05 ` Greg Kurz
2020-05-14 10:49 ` [PULL 0/4] 9p patches 2020-05-14 Peter Maydell
4 siblings, 0 replies; 6+ messages in thread
From: Greg Kurz @ 2020-05-14 9:05 UTC (permalink / raw)
To: qemu-devel, Peter Maydell
Cc: Stefano Stabellini, Christian Schoenebeck, Greg Kurz
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
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 <qemu_oss@crudebyte.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Message-Id: <ad0e5a9b6abde52502aa40b30661d29aebe1590a.1589132512.git.qemu_oss@crudebyte.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
---
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 18fe5b7c92fa..f04caabfe51e 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);
}
--
2.21.3
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PULL 0/4] 9p patches 2020-05-14
2020-05-14 9:05 [PULL 0/4] 9p patches 2020-05-14 Greg Kurz
` (3 preceding siblings ...)
2020-05-14 9:05 ` [PULL 4/4] xen-9pfs: Fix log messages of reply errors Greg Kurz
@ 2020-05-14 10:49 ` Peter Maydell
4 siblings, 0 replies; 6+ messages in thread
From: Peter Maydell @ 2020-05-14 10:49 UTC (permalink / raw)
To: Greg Kurz; +Cc: Christian Schoenebeck, QEMU Developers
On Thu, 14 May 2020 at 10:05, Greg Kurz <groug@kaod.org> wrote:
>
> The following changes since commit d5c75ec500d96f1d93447f990cd5a4ef5ba27fae:
>
> Merge remote-tracking branch 'remotes/stefanberger/tags/pull-tpm-2020-05-08-1' into staging (2020-05-12 17:00:10 +0100)
>
> are available in the Git repository at:
>
> https://github.com/gkurz/qemu.git tags/9p-next-2020-05-14
>
> for you to fetch changes up to 9bbb7e0fe081efff2e41f8517c256b72a284fe9b:
>
> xen-9pfs: Fix log messages of reply errors (2020-05-14 08:06:43 +0200)
>
> ----------------------------------------------------------------
> Changes:
> - Christian Schoenebeck is now co-maintainer for 9pfs
> - relax checks for O_NOATIME
> - minor documentation updates
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/5.1
for any user-visible changes.
-- PMM
^ permalink raw reply [flat|nested] 6+ messages in thread