[RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Bin Meng]

At present there is no Windows support for 9p file system.
This series adds initial Windows support for 9p file system.

Only 'local' file system driver backend is supported. security_model
should be 'none' due to limitations on Windows host.

Example command line to test:

  "-fsdev local,path=c:\msys64,security_model=none,id=p9 -device virtio-9p-pci,fsdev=p9,mount_tag=p9fs"


Guohuai Shi (4):
  fsdev: Add missing definitions for Windows in file-op-9p.h
  hw/9pfs: Update 'local' file system backend driver to support Windows
  fsdev: Enable 'local' file system driver backend for Windows
  meson.build: Turn on virtfs for Windows host

 meson.build         |  10 +-
 fsdev/file-op-9p.h  |  33 ++++++
 hw/9pfs/9p-util.h   |   4 +
 hw/9pfs/9p.h        |  22 ++++
 fsdev/qemu-fsdev.c  |   2 +
 hw/9pfs/9p-local.c  | 273 +++++++++++++++++++++++++++++++++++++++++++-
 hw/9pfs/9p.c        |  85 +++++++++++++-
 hw/9pfs/codir.c     |  17 +++
 fsdev/meson.build   |   1 +
 hw/9pfs/meson.build |  10 +-
 10 files changed, 449 insertions(+), 8 deletions(-)

-- 
2.25.1

[RFC PATCH 1/4] fsdev: Add missing definitions for Windows in file-op-9p.h

[Bin Meng]

From: Guohuai Shi <guohuai.shi@windriver.com>

Add uid_t, gid_t and struct statfs definitions, which are currently
missing from Windows headers, but are required when we add 9p file
system support for Windows in later patches.

Signed-off-by: Guohuai Shi <guohuai.shi@windriver.com>
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---

 fsdev/file-op-9p.h | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h
index 4997677460..7d9a736b66 100644
--- a/fsdev/file-op-9p.h
+++ b/fsdev/file-op-9p.h
@@ -27,6 +27,39 @@
 # include <sys/mount.h>
 #endif
 
+#ifdef CONFIG_WIN32
+
+/* POSIX structure not defined in Windows */
+
+typedef uint32_t uid_t;
+typedef uint32_t gid_t;
+
+/* from http://man7.org/linux/man-pages/man2/statfs.2.html */
+typedef uint32_t __fsword_t;
+typedef uint32_t fsblkcnt_t;
+typedef uint32_t fsfilcnt_t;
+
+/* from linux/include/uapi/asm-generic/posix_types.h */
+typedef struct {
+    long __val[2];
+} fsid_t;
+
+struct statfs {
+    __fsword_t f_type;
+    __fsword_t f_bsize;
+    fsblkcnt_t f_blocks;
+    fsblkcnt_t f_bfree;
+    fsblkcnt_t f_bavail;
+    fsfilcnt_t f_files;
+    fsfilcnt_t f_ffree;
+    fsid_t f_fsid;
+    __fsword_t f_namelen;
+    __fsword_t f_frsize;
+    __fsword_t f_flags;
+};
+
+#endif /* CONFIG_WIN32 */
+
 #define SM_LOCAL_MODE_BITS    0600
 #define SM_LOCAL_DIR_MODE_BITS    0700
 
-- 
2.25.1

[RFC PATCH 2/4] hw/9pfs: Update 'local' file system backend driver to support Windows

[Bin Meng]

From: Guohuai Shi <guohuai.shi@windriver.com>

Extend the 9p local file system backend driver to support Windows,
including open, read, write, close, rename, remove, etc.

Symbolic link, link, chmod, renameat, unlinkat and extended attribute
are not supported due to limitations on Windows host.

Signed-off-by: Guohuai Shi <guohuai.shi@windriver.com>
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---

 hw/9pfs/9p-util.h   |   4 +
 hw/9pfs/9p.h        |  22 ++++
 hw/9pfs/9p-local.c  | 273 +++++++++++++++++++++++++++++++++++++++++++-
 hw/9pfs/9p.c        |  85 +++++++++++++-
 hw/9pfs/codir.c     |  17 +++
 hw/9pfs/meson.build |  10 +-
 6 files changed, 408 insertions(+), 3 deletions(-)

diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index 97e681e167..44c584c9ef 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -43,6 +43,7 @@ static inline void close_preserve_errno(int fd)
     errno = serrno;
 }
 
+#ifndef CONFIG_WIN32
 static inline int openat_dir(int dirfd, const char *name)
 {
     return openat(dirfd, name,
@@ -89,6 +90,7 @@ again:
     errno = serrno;
     return fd;
 }
+#endif /* !CONFIG_WIN32 */
 
 ssize_t fgetxattrat_nofollow(int dirfd, const char *path, const char *name,
                              void *value, size_t size);
@@ -99,6 +101,7 @@ ssize_t flistxattrat_nofollow(int dirfd, const char *filename,
 ssize_t fremovexattrat_nofollow(int dirfd, const char *filename,
                                 const char *name);
 
+#ifndef CONFIG_WIN32
 /*
  * Darwin has d_seekoff, which appears to function similarly to d_off.
  * However, it does not appear to be supported on all file systems,
@@ -113,6 +116,7 @@ static inline off_t qemu_dirent_off(struct dirent *dent)
     return dent->d_off;
 #endif
 }
+#endif /* !CONFIG_WIN32 */
 
 /**
  * qemu_dirent_dup() - Duplicate directory entry @dent.
diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index 994f952600..171b907832 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -3,12 +3,34 @@
 
 #include <dirent.h>
 #include <utime.h>
+#ifndef CONFIG_WIN32
 #include <sys/resource.h>
+#endif
 #include "fsdev/file-op-9p.h"
 #include "fsdev/9p-iov-marshal.h"
 #include "qemu/thread.h"
 #include "qemu/coroutine.h"
 #include "qemu/qht.h"
+#ifdef CONFIG_WIN32
+
+#define O_NOCTTY            0
+#define O_NDELAY            0
+#define O_NONBLOCK          0
+#define O_DSYNC             0
+#define O_DIRECT            0
+#define O_NOFOLLOW          0
+#define O_NOATIME           0
+#define O_SYNC              0
+#define O_ASYNC             0
+#define O_DIRECTORY         02000000
+
+#define FASYNC              0
+
+#define AT_REMOVEDIR        1
+
+#define NAME_MAX            260
+
+#endif
 
 enum {
     P9_TLERROR = 6,
diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
index d42ce6d8b8..acc62d5fb9 100644
--- a/hw/9pfs/9p-local.c
+++ b/hw/9pfs/9p-local.c
@@ -18,15 +18,22 @@
 #include "qemu/osdep.h"
 #include "9p.h"
 #include "9p-local.h"
+#ifndef CONFIG_WIN32
 #include "9p-xattr.h"
+#endif
 #include "9p-util.h"
 #include "fsdev/qemu-fsdev.h"   /* local_ops */
+#ifndef CONFIG_WIN32
 #include <arpa/inet.h>
 #include <pwd.h>
 #include <grp.h>
 #include <sys/socket.h>
 #include <sys/un.h>
 #include "qemu/xattr.h"
+#else
+#include <dirent.h>
+#endif
+
 #include "qapi/error.h"
 #include "qemu/cutils.h"
 #include "qemu/error-report.h"
@@ -38,7 +45,9 @@
 #include <linux/magic.h>
 #endif
 #endif
+#ifndef CONFIG_WIN32
 #include <sys/ioctl.h>
+#endif
 
 #ifndef XFS_SUPER_MAGIC
 #define XFS_SUPER_MAGIC  0x58465342
@@ -57,9 +66,68 @@ typedef struct {
     int mountfd;
 } LocalData;
 
+#ifdef CONFIG_WIN32
+static inline char *merge_fs_path(const char *path1, const char *path2)
+{
+    char *full_fs_path;
+    size_t full_fs_path_len;
+
+    full_fs_path_len = strlen(path1) + strlen(path2) +  2;
+    full_fs_path = g_malloc(full_fs_path_len);
+
+    strcpy(full_fs_path, path1);
+    strcat(full_fs_path, "\\");
+    strcat(full_fs_path, path2);
+
+    return full_fs_path;
+}
+
+static inline int opendir_with_ctx(FsContext *fs_ctx, const char *name)
+{
+    /* Windows do not support open a directory by open() */
+    return -1;
+}
+
+static inline int openfile_with_ctx(FsContext *fs_ctx, const char *name,
+                                    int flags, mode_t mode)
+{
+    char *full_fs_path;
+    int fd;
+
+    full_fs_path = merge_fs_path(fs_ctx->fs_root, name);
+    fd = open(full_fs_path, flags, mode);
+    g_free(full_fs_path);
+
+    return fd;
+}
+
+static inline int mkdir_with_ctx(FsContext *fs_ctx, const char *name)
+{
+    char *full_fs_path;
+    int fd;
+
+    full_fs_path = merge_fs_path(fs_ctx->fs_root, name);
+    fd = mkdir(full_fs_path);
+    g_free(full_fs_path);
+
+    return fd;
+}
+#endif
+
 int local_open_nofollow(FsContext *fs_ctx, const char *path, int flags,
                         mode_t mode)
 {
+#ifdef CONFIG_WIN32
+    int fd;
+
+    if (path[strlen(path) - 1] == '/' || (flags & O_DIRECTORY) != 0) {
+        fd = opendir_with_ctx(fs_ctx, path);
+    } else {
+        fd = openfile_with_ctx(fs_ctx, path, flags, mode);
+    }
+
+    return fd;
+#else
     LocalData *data = fs_ctx->private;
     int fd = data->mountfd;
 
@@ -92,6 +160,7 @@ int local_open_nofollow(FsContext *fs_ctx, const char *path, int flags,
 
     assert(fd != data->mountfd);
     return fd;
+#endif
 }
 
 int local_opendir_nofollow(FsContext *fs_ctx, const char *path)
@@ -99,6 +168,7 @@ int local_opendir_nofollow(FsContext *fs_ctx, const char *path)
     return local_open_nofollow(fs_ctx, path, O_DIRECTORY | O_RDONLY, 0);
 }
 
+#ifndef CONFIG_WIN32
 static void renameat_preserve_errno(int odirfd, const char *opath, int ndirfd,
                                     const char *npath)
 {
@@ -181,12 +251,15 @@ static void local_mapped_file_attr(int dirfd, const char *name,
     }
     fclose(fp);
 }
+#endif /* !CONFIG_WIN32 */
 
 static int local_lstat(FsContext *fs_ctx, V9fsPath *fs_path, struct stat *stbuf)
 {
     int err = -1;
     char *dirpath = g_path_get_dirname(fs_path->data);
     char *name = g_path_get_basename(fs_path->data);
+
+#ifndef CONFIG_WIN32
     int dirfd;
 
     dirfd = local_opendir_nofollow(fs_ctx, dirpath);
@@ -195,9 +268,21 @@ static int local_lstat(FsContext *fs_ctx, V9fsPath *fs_path, struct stat *stbuf)
     }
 
     err = fstatat(dirfd, name, stbuf, AT_SYMLINK_NOFOLLOW);
+#else
+    char *full_fs_path1, *full_fs_path2;
+
+    full_fs_path1 = merge_fs_path(fs_ctx->fs_root, dirpath);
+    full_fs_path2 = merge_fs_path(full_fs_path1, name);
+    err = stat(full_fs_path2, stbuf);
+
+    g_free(full_fs_path1);
+    g_free(full_fs_path2);
+#endif
     if (err) {
         goto err_out;
     }
+
+#ifndef CONFIG_WIN32
     if (fs_ctx->export_flags & V9FS_SM_MAPPED) {
         /* Actual credentials are part of extended attrs */
         uid_t tmp_uid;
@@ -224,15 +309,19 @@ static int local_lstat(FsContext *fs_ctx, V9fsPath *fs_path, struct stat *stbuf)
     } else if (fs_ctx->export_flags & V9FS_SM_MAPPED_FILE) {
         local_mapped_file_attr(dirfd, name, stbuf);
     }
+#endif
 
 err_out:
+#ifndef CONFIG_WIN32
     close_preserve_errno(dirfd);
 out:
+#endif
     g_free(name);
     g_free(dirpath);
     return err;
 }
 
+#ifndef CONFIG_WIN32
 static int local_set_mapped_file_attrat(int dirfd, const char *name,
                                         FsCred *credp)
 {
@@ -456,10 +545,14 @@ static int local_set_cred_passthrough(FsContext *fs_ctx, int dirfd,
 
     return fchmodat_nofollow(dirfd, name, credp->fc_mode & 07777);
 }
+#endif /* !CONFIG_WIN32 */
 
 static ssize_t local_readlink(FsContext *fs_ctx, V9fsPath *fs_path,
                               char *buf, size_t bufsz)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     ssize_t tsize = -1;
 
     if ((fs_ctx->export_flags & V9FS_SM_MAPPED) ||
@@ -492,6 +585,7 @@ static ssize_t local_readlink(FsContext *fs_ctx, V9fsPath *fs_path,
         g_free(dirpath);
     }
     return tsize;
+#endif
 }
 
 static int local_close(FsContext *ctx, V9fsFidOpenState *fs)
@@ -520,9 +614,21 @@ static int local_open(FsContext *ctx, V9fsPath *fs_path,
 static int local_opendir(FsContext *ctx,
                          V9fsPath *fs_path, V9fsFidOpenState *fs)
 {
-    int dirfd;
     DIR *stream;
 
+#ifdef CONFIG_WIN32
+    char *full_fs_path;
+
+    full_fs_path = merge_fs_path(ctx->fs_root, fs_path->data);
+    stream = opendir(full_fs_path);
+    g_free(full_fs_path);
+
+    if (!stream) {
+        return -1;
+    }
+#else
+    int dirfd;
+
     dirfd = local_opendir_nofollow(ctx, fs_path->data);
     if (dirfd == -1) {
         return -1;
@@ -533,6 +639,7 @@ static int local_opendir(FsContext *ctx,
         close(dirfd);
         return -1;
     }
+#endif
     fs->dir.stream = stream;
     return 0;
 }
@@ -547,17 +654,21 @@ static off_t local_telldir(FsContext *ctx, V9fsFidOpenState *fs)
     return telldir(fs->dir.stream);
 }
 
+#ifndef CONFIG_WIN32
 static bool local_is_mapped_file_metadata(FsContext *fs_ctx, const char *name)
 {
     return
         !strcmp(name, VIRTFS_META_DIR) || !strcmp(name, VIRTFS_META_ROOT_FILE);
 }
+#endif
 
 static struct dirent *local_readdir(FsContext *ctx, V9fsFidOpenState *fs)
 {
     struct dirent *entry;
 
+#ifndef CONFIG_WIN32
 again:
+#endif
     entry = readdir(fs->dir.stream);
     if (!entry) {
         return NULL;
@@ -572,6 +683,7 @@ again:
     entry->d_seekoff = off;
 #endif
 
+#ifndef CONFIG_WIN32
     if (ctx->export_flags & V9FS_SM_MAPPED) {
         entry->d_type = DT_UNKNOWN;
     } else if (ctx->export_flags & V9FS_SM_MAPPED_FILE) {
@@ -581,6 +693,7 @@ again:
         }
         entry->d_type = DT_UNKNOWN;
     }
+#endif
 
     return entry;
 }
@@ -637,6 +750,9 @@ static ssize_t local_pwritev(FsContext *ctx, V9fsFidOpenState *fs,
 
 static int local_chmod(FsContext *fs_ctx, V9fsPath *fs_path, FsCred *credp)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     char *dirpath = g_path_get_dirname(fs_path->data);
     char *name = g_path_get_basename(fs_path->data);
     int ret = -1;
@@ -661,11 +777,15 @@ out:
     g_free(dirpath);
     g_free(name);
     return ret;
+#endif
 }
 
 static int local_mknod(FsContext *fs_ctx, V9fsPath *dir_path,
                        const char *name, FsCred *credp)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     int err = -1;
     int dirfd;
 
@@ -713,12 +833,14 @@ err_end:
 out:
     close_preserve_errno(dirfd);
     return err;
+#endif
 }
 
 static int local_mkdir(FsContext *fs_ctx, V9fsPath *dir_path,
                        const char *name, FsCred *credp)
 {
     int err = -1;
+#ifndef CONFIG_WIN32
     int dirfd;
 
     if (fs_ctx->export_flags & V9FS_SM_MAPPED_FILE &&
@@ -759,13 +881,25 @@ static int local_mkdir(FsContext *fs_ctx, V9fsPath *dir_path,
             goto err_end;
         }
     }
+#else
+    char *full_fs_path;
+
+    full_fs_path = merge_fs_path(dir_path->data, name);
+    err = mkdir_with_ctx(fs_ctx, full_fs_path);
+    g_free(full_fs_path);
+#endif
     goto out;
 
+#ifndef CONFIG_WIN32
 err_end:
     unlinkat_preserve_errno(dirfd, name, AT_REMOVEDIR);
 out:
     close_preserve_errno(dirfd);
     return err;
+#else
+out:
+    return err;
+#endif
 }
 
 static int local_fstat(FsContext *fs_ctx, int fid_type,
@@ -774,7 +908,9 @@ static int local_fstat(FsContext *fs_ctx, int fid_type,
     int err, fd;
 
     if (fid_type == P9_FID_DIR) {
+#ifndef CONFIG_WIN32
         fd = dirfd(fs->dir.stream);
+#endif
     } else {
         fd = fs->fd;
     }
@@ -783,6 +919,7 @@ static int local_fstat(FsContext *fs_ctx, int fid_type,
     if (err) {
         return err;
     }
+#ifndef CONFIG_WIN32
     if (fs_ctx->export_flags & V9FS_SM_MAPPED) {
         /* Actual credentials are part of extended attrs */
         uid_t tmp_uid;
@@ -810,6 +947,8 @@ static int local_fstat(FsContext *fs_ctx, int fid_type,
         errno = EOPNOTSUPP;
         return -1;
     }
+#endif
+
     return err;
 }
 
@@ -818,6 +957,8 @@ static int local_open2(FsContext *fs_ctx, V9fsPath *dir_path, const char *name,
 {
     int fd = -1;
     int err = -1;
+
+#ifndef CONFIG_WIN32
     int dirfd;
 
     if (fs_ctx->export_flags & V9FS_SM_MAPPED_FILE &&
@@ -864,16 +1005,27 @@ static int local_open2(FsContext *fs_ctx, V9fsPath *dir_path, const char *name,
             goto err_end;
         }
     }
+#else
+    char *full_fs_path;
+
+    full_fs_path = merge_fs_path(dir_path->data, name);
+    fd = openfile_with_ctx(fs_ctx, full_fs_path, flags, credp->fc_mode);
+    g_free(full_fs_path);
+#endif
     err = fd;
     fs->fd = fd;
     goto out;
 
+#ifndef CONFIG_WIN32
 err_end:
     unlinkat_preserve_errno(dirfd, name,
                             flags & O_DIRECTORY ? AT_REMOVEDIR : 0);
+#endif
     close_preserve_errno(fd);
 out:
+#ifndef CONFIG_WIN32
     close_preserve_errno(dirfd);
+#endif
     return err;
 }
 
@@ -881,6 +1033,9 @@ out:
 static int local_symlink(FsContext *fs_ctx, const char *oldpath,
                          V9fsPath *dir_path, const char *name, FsCred *credp)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     int err = -1;
     int dirfd;
 
@@ -954,11 +1109,15 @@ err_end:
 out:
     close_preserve_errno(dirfd);
     return err;
+#endif
 }
 
 static int local_link(FsContext *ctx, V9fsPath *oldpath,
                       V9fsPath *dirpath, const char *name)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     char *odirpath = g_path_get_dirname(oldpath->data);
     char *oname = g_path_get_basename(oldpath->data);
     int ret = -1;
@@ -1028,6 +1187,7 @@ out:
     g_free(oname);
     g_free(odirpath);
     return ret;
+#endif
 }
 
 static int local_truncate(FsContext *ctx, V9fsPath *fs_path, off_t size)
@@ -1045,6 +1205,9 @@ static int local_truncate(FsContext *ctx, V9fsPath *fs_path, off_t size)
 
 static int local_chown(FsContext *fs_ctx, V9fsPath *fs_path, FsCred *credp)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     char *dirpath = g_path_get_dirname(fs_path->data);
     char *name = g_path_get_basename(fs_path->data);
     int ret = -1;
@@ -1071,11 +1234,26 @@ out:
     g_free(name);
     g_free(dirpath);
     return ret;
+#endif
 }
 
 static int local_utimensat(FsContext *s, V9fsPath *fs_path,
                            const struct timespec *buf)
 {
+#ifdef CONFIG_WIN32
+    struct utimbuf tm;
+    char *full_fs_path;
+    int err;
+
+    tm.actime = buf[0].tv_sec;
+    tm.modtime = buf[1].tv_sec;
+
+    full_fs_path = merge_fs_path(s->fs_root, fs_path->data);
+    err = utime(full_fs_path, &tm);
+    g_free(full_fs_path);
+
+    return err;
+#else
     char *dirpath = g_path_get_dirname(fs_path->data);
     char *name = g_path_get_basename(fs_path->data);
     int dirfd, ret = -1;
@@ -1091,8 +1269,10 @@ out:
     g_free(dirpath);
     g_free(name);
     return ret;
+#endif
 }
 
+#ifndef CONFIG_WIN32
 static int local_unlinkat_common(FsContext *ctx, int dirfd, const char *name,
                                  int flags)
 {
@@ -1136,9 +1316,27 @@ static int local_unlinkat_common(FsContext *ctx, int dirfd, const char *name,
 
     return unlinkat(dirfd, name, flags);
 }
+#endif /* !CONFIG_WIN32 */
 
 static int local_remove(FsContext *ctx, const char *path)
 {
+#ifdef CONFIG_WIN32
+    int err;
+    DIR *stream;
+    char *full_fs_path;
+
+    full_fs_path = merge_fs_path(ctx->fs_root, path);
+    stream = opendir(full_fs_path);
+    if (stream == NULL) {
+        err = remove(full_fs_path);
+    } else {
+        closedir(stream);
+        err = rmdir(full_fs_path);
+    }
+
+    g_free(full_fs_path);
+    return err;
+#else
     struct stat stbuf;
     char *dirpath = g_path_get_dirname(path);
     char *name = g_path_get_basename(path);
@@ -1166,11 +1364,15 @@ out:
     g_free(name);
     g_free(dirpath);
     return err;
+#endif
 }
 
 static int local_fsync(FsContext *ctx, int fid_type,
                        V9fsFidOpenState *fs, int datasync)
 {
+#ifdef CONFIG_WIN32
+    return 0;
+#else
     int fd;
 
     if (fid_type == P9_FID_DIR) {
@@ -1184,10 +1386,14 @@ static int local_fsync(FsContext *ctx, int fid_type,
     } else {
         return fsync(fd);
     }
+#endif
 }
 
 static int local_statfs(FsContext *s, V9fsPath *fs_path, struct statfs *stbuf)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     int fd, ret;
 
     fd = local_open_nofollow(s, fs_path->data, O_RDONLY, 0);
@@ -1197,48 +1403,67 @@ static int local_statfs(FsContext *s, V9fsPath *fs_path, struct statfs *stbuf)
     ret = fstatfs(fd, stbuf);
     close_preserve_errno(fd);
     return ret;
+#endif
 }
 
 static ssize_t local_lgetxattr(FsContext *ctx, V9fsPath *fs_path,
                                const char *name, void *value, size_t size)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     char *path = fs_path->data;
 
     return v9fs_get_xattr(ctx, path, name, value, size);
+#endif
 }
 
 static ssize_t local_llistxattr(FsContext *ctx, V9fsPath *fs_path,
                                 void *value, size_t size)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     char *path = fs_path->data;
 
     return v9fs_list_xattr(ctx, path, value, size);
+#endif
 }
 
 static int local_lsetxattr(FsContext *ctx, V9fsPath *fs_path, const char *name,
                            void *value, size_t size, int flags)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     char *path = fs_path->data;
 
     return v9fs_set_xattr(ctx, path, name, value, size, flags);
+#endif
 }
 
 static int local_lremovexattr(FsContext *ctx, V9fsPath *fs_path,
                               const char *name)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     char *path = fs_path->data;
 
     return v9fs_remove_xattr(ctx, path, name);
+#endif
 }
 
 static int local_name_to_path(FsContext *ctx, V9fsPath *dir_path,
                               const char *name, V9fsPath *target)
 {
+#ifndef CONFIG_WIN32
     if (ctx->export_flags & V9FS_SM_MAPPED_FILE &&
         local_is_mapped_file_metadata(ctx, name)) {
         errno = EINVAL;
         return -1;
     }
+#endif
 
     if (dir_path) {
         if (!strcmp(name, ".")) {
@@ -1275,6 +1500,9 @@ static int local_renameat(FsContext *ctx, V9fsPath *olddir,
                           const char *old_name, V9fsPath *newdir,
                           const char *new_name)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     int ret;
     int odirfd, ndirfd;
 
@@ -1340,18 +1568,34 @@ out:
     close_preserve_errno(ndirfd);
     close_preserve_errno(odirfd);
     return ret;
+#endif
 }
 
+#ifndef CONFIG_WIN32
 static void v9fs_path_init_dirname(V9fsPath *path, const char *str)
 {
     path->data = g_path_get_dirname(str);
     path->size = strlen(path->data) + 1;
 }
+#endif
 
 static int local_rename(FsContext *ctx, const char *oldpath,
                         const char *newpath)
 {
     int err;
+
+#ifdef CONFIG_WIN32
+    char *full_fs_path1;
+    char *full_fs_path2;
+
+    full_fs_path1 = merge_fs_path(ctx->fs_root, oldpath);
+    full_fs_path2 = merge_fs_path(ctx->fs_root, newpath);
+
+    err = rename(full_fs_path1, full_fs_path2);
+
+    g_free(full_fs_path1);
+    g_free(full_fs_path2);
+#else
     char *oname = g_path_get_basename(oldpath);
     char *nname = g_path_get_basename(newpath);
     V9fsPath olddir, newdir;
@@ -1365,6 +1609,7 @@ static int local_rename(FsContext *ctx, const char *oldpath,
     v9fs_path_free(&olddir);
     g_free(nname);
     g_free(oname);
+#endif
 
     return err;
 }
@@ -1372,6 +1617,9 @@ static int local_rename(FsContext *ctx, const char *oldpath,
 static int local_unlinkat(FsContext *ctx, V9fsPath *dir,
                           const char *name, int flags)
 {
+#ifdef CONFIG_WIN32
+    return -1;
+#else
     int ret;
     int dirfd;
 
@@ -1389,6 +1637,7 @@ static int local_unlinkat(FsContext *ctx, V9fsPath *dir,
     ret = local_unlinkat_common(ctx, dirfd, name, flags);
     close_preserve_errno(dirfd);
     return ret;
+#endif
 }
 
 #ifdef FS_IOC_GETVERSION
@@ -1416,6 +1665,7 @@ static int local_ioc_getversion(FsContext *ctx, V9fsPath *path,
 }
 #endif
 
+#ifndef CONFIG_WIN32
 static int local_ioc_getversion_init(FsContext *ctx, LocalData *data, Error **errp)
 {
 #ifdef FS_IOC_GETVERSION
@@ -1440,9 +1690,29 @@ static int local_ioc_getversion_init(FsContext *ctx, LocalData *data, Error **er
 #endif
     return 0;
 }
+#endif
+
 
 static int local_init(FsContext *ctx, Error **errp)
 {
+#ifdef CONFIG_WIN32
+    LocalData *data = g_malloc(sizeof(*data));
+    struct stat StatBuf;
+
+    if (stat(ctx->fs_root, &StatBuf) != 0) {
+        error_setg_errno(errp, errno, "failed to open '%s'", ctx->fs_root);
+        goto err;
+    }
+
+    ctx->export_flags |= V9FS_PATHNAME_FSCONTEXT;
+
+    ctx->private = data;
+    return 0;
+
+err:
+    g_free(data);
+    return -1;
+#else
     LocalData *data = g_malloc(sizeof(*data));
 
     data->mountfd = open(ctx->fs_root, O_DIRECTORY | O_RDONLY);
@@ -1477,6 +1747,7 @@ static int local_init(FsContext *ctx, Error **errp)
 err:
     g_free(data);
     return -1;
+#endif
 }
 
 static void local_cleanup(FsContext *ctx)
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 225f31fc31..5c7a53841e 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -31,13 +31,19 @@
 #include "qemu/sockets.h"
 #include "virtio-9p.h"
 #include "fsdev/qemu-fsdev.h"
+#ifndef CONFIG_WIN32
 #include "9p-xattr.h"
+#endif
 #include "9p-util.h"
 #include "coth.h"
 #include "trace.h"
 #include "migration/blocker.h"
 #include "qemu/xxhash.h"
 #include <math.h>
+#ifdef CONFIG_WIN32
+#define UTIME_NOW   ((1l << 30) - 1l)
+#define UTIME_OMIT  ((1l << 30) - 2l)
+#endif
 
 int open_fd_hw;
 int total_open_fd;
@@ -986,9 +992,11 @@ static int stat_to_qid(V9fsPDU *pdu, const struct stat *stbuf, V9fsQID *qidp)
     if (S_ISDIR(stbuf->st_mode)) {
         qidp->type |= P9_QID_TYPE_DIR;
     }
+#ifndef CONFIG_WIN32
     if (S_ISLNK(stbuf->st_mode)) {
         qidp->type |= P9_QID_TYPE_SYMLINK;
     }
+#endif
 
     return 0;
 }
@@ -1095,6 +1103,7 @@ static mode_t v9mode_to_mode(uint32_t mode, V9fsString *extension)
         ret |= S_IFDIR;
     }
 
+#ifndef CONFIG_WIN32
     if (mode & P9_STAT_MODE_SYMLINK) {
         ret |= S_IFLNK;
     }
@@ -1104,6 +1113,7 @@ static mode_t v9mode_to_mode(uint32_t mode, V9fsString *extension)
     if (mode & P9_STAT_MODE_NAMED_PIPE) {
         ret |= S_IFIFO;
     }
+#endif
     if (mode & P9_STAT_MODE_DEVICE) {
         if (extension->size && extension->data[0] == 'c') {
             ret |= S_IFCHR;
@@ -1116,6 +1126,7 @@ static mode_t v9mode_to_mode(uint32_t mode, V9fsString *extension)
         ret |= S_IFREG;
     }
 
+#ifndef CONFIG_WIN32
     if (mode & P9_STAT_MODE_SETUID) {
         ret |= S_ISUID;
     }
@@ -1125,6 +1136,7 @@ static mode_t v9mode_to_mode(uint32_t mode, V9fsString *extension)
     if (mode & P9_STAT_MODE_SETVTX) {
         ret |= S_ISVTX;
     }
+#endif
 
     return ret;
 }
@@ -1180,6 +1192,7 @@ static uint32_t stat_to_v9mode(const struct stat *stbuf)
         mode |= P9_STAT_MODE_DIR;
     }
 
+#ifndef CONFIG_WIN32
     if (S_ISLNK(stbuf->st_mode)) {
         mode |= P9_STAT_MODE_SYMLINK;
     }
@@ -1191,11 +1204,13 @@ static uint32_t stat_to_v9mode(const struct stat *stbuf)
     if (S_ISFIFO(stbuf->st_mode)) {
         mode |= P9_STAT_MODE_NAMED_PIPE;
     }
+#endif
 
     if (S_ISBLK(stbuf->st_mode) || S_ISCHR(stbuf->st_mode)) {
         mode |= P9_STAT_MODE_DEVICE;
     }
 
+#ifndef CONFIG_WIN32
     if (stbuf->st_mode & S_ISUID) {
         mode |= P9_STAT_MODE_SETUID;
     }
@@ -1207,6 +1222,7 @@ static uint32_t stat_to_v9mode(const struct stat *stbuf)
     if (stbuf->st_mode & S_ISVTX) {
         mode |= P9_STAT_MODE_SETVTX;
     }
+#endif
 
     return mode;
 }
@@ -1245,9 +1261,16 @@ static int coroutine_fn stat_to_v9stat(V9fsPDU *pdu, V9fsPath *path,
             return err;
         }
     } else if (v9stat->mode & P9_STAT_MODE_DEVICE) {
+#ifndef CONFIG_WIN32
         v9fs_string_sprintf(&v9stat->extension, "%c %u %u",
                 S_ISCHR(stbuf->st_mode) ? 'c' : 'b',
                 major(stbuf->st_rdev), minor(stbuf->st_rdev));
+#else
+        v9fs_string_sprintf(&v9stat->extension, "%c %u %u",
+                S_ISCHR(stbuf->st_mode) ? 'c' : 'b',
+                0, 0);
+#endif
+
     } else if (S_ISDIR(stbuf->st_mode) || S_ISREG(stbuf->st_mode)) {
         v9fs_string_sprintf(&v9stat->extension, "%s %lu",
                 "HARDLINKCOUNT", (unsigned long)stbuf->st_nlink);
@@ -1315,7 +1338,11 @@ static int32_t blksize_to_iounit(const V9fsPDU *pdu, int32_t blksize)
 
 static int32_t stat_to_iounit(const V9fsPDU *pdu, const struct stat *stbuf)
 {
+#ifndef CONFIG_WIN32
     return blksize_to_iounit(pdu, stbuf->st_blksize);
+#else
+    return blksize_to_iounit(pdu, 0);
+#endif
 }
 
 static int stat_to_v9stat_dotl(V9fsPDU *pdu, const struct stat *stbuf,
@@ -1329,6 +1356,14 @@ static int stat_to_v9stat_dotl(V9fsPDU *pdu, const struct stat *stbuf,
     v9lstat->st_gid = stbuf->st_gid;
     v9lstat->st_rdev = stbuf->st_rdev;
     v9lstat->st_size = stbuf->st_size;
+
+#ifdef CONFIG_WIN32
+    v9lstat->st_blksize = stat_to_iounit(pdu, stbuf);
+    v9lstat->st_blocks = 0;
+    v9lstat->st_atime_sec = stbuf->st_atime;
+    v9lstat->st_mtime_sec = stbuf->st_mtime;
+    v9lstat->st_ctime_sec = stbuf->st_ctime;
+#else /* !CONFIG_WIN32 */
     v9lstat->st_blksize = stat_to_iounit(pdu, stbuf);
     v9lstat->st_blocks = stbuf->st_blocks;
     v9lstat->st_atime_sec = stbuf->st_atime;
@@ -1343,6 +1378,8 @@ static int stat_to_v9stat_dotl(V9fsPDU *pdu, const struct stat *stbuf,
     v9lstat->st_mtime_nsec = stbuf->st_mtim.tv_nsec;
     v9lstat->st_ctime_nsec = stbuf->st_ctim.tv_nsec;
 #endif
+#endif /* CONFIG_WIN32 */
+
     /* Currently we only support BASIC fields in stat */
     v9lstat->st_result_mask = P9_STATS_BASIC;
 
@@ -2300,7 +2337,11 @@ static int coroutine_fn v9fs_do_readdir_with_stat(V9fsPDU *pdu,
         count += len;
         v9fs_stat_free(&v9stat);
         v9fs_path_free(&path);
+#ifndef CONFIG_WIN32
         saved_dir_pos = qemu_dirent_off(dent);
+#else
+        saved_dir_pos = v9fs_co_telldir(pdu, fidp);
+#endif
     }
 
     v9fs_readdir_unlock(&fidp->fs.dir);
@@ -2501,14 +2542,28 @@ static int coroutine_fn v9fs_do_readdir(V9fsPDU *pdu, V9fsFidState *fidp,
             qid.version = 0;
         }
 
+#ifdef CONFIG_WIN32
+        /*
+         * Windows does not have dent->d_off, get offset by calling telldir()
+         * manually.
+         */
+        off = v9fs_co_telldir(pdu, fidp);
+#else
         off = qemu_dirent_off(dent);
+#endif
         v9fs_string_init(&name);
         v9fs_string_sprintf(&name, "%s", dent->d_name);
 
+#ifdef CONFIG_WIN32
+        len = pdu_marshal(pdu, 11 + count, "Qqbs",
+                          &qid, off,
+                          0, &name);
+#else
         /* 11 = 7 + 4 (7 = start offset, 4 = space for storing count) */
         len = pdu_marshal(pdu, 11 + count, "Qqbs",
                           &qid, off,
                           dent->d_type, &name);
+#endif
 
         v9fs_string_free(&name);
 
@@ -2838,8 +2893,14 @@ static void coroutine_fn v9fs_create(void *opaque)
         }
 
         nmode |= perm & 0777;
+
+#ifndef CONFIG_WIN32
         err = v9fs_co_mknod(pdu, fidp, &name, fidp->uid, -1,
                             makedev(major, minor), nmode, &stbuf);
+#else
+        err = -ENOTSUP;
+#endif
+
         if (err < 0) {
             goto out;
         }
@@ -2864,8 +2925,12 @@ static void coroutine_fn v9fs_create(void *opaque)
         v9fs_path_copy(&fidp->path, &path);
         v9fs_path_unlock(s);
     } else if (perm & P9_STAT_MODE_SOCKET) {
+#ifndef CONFIG_WIN32
         err = v9fs_co_mknod(pdu, fidp, &name, fidp->uid, -1,
                             0, S_IFSOCK | (perm & 0777), &stbuf);
+#else
+        err = -ENOTSUP;
+#endif
         if (err < 0) {
             goto out;
         }
@@ -3600,6 +3665,7 @@ out_nofid:
 static void coroutine_fn v9fs_mknod(void *opaque)
 {
 
+#ifndef CONFIG_WIN32
     int mode;
     gid_t gid;
     int32_t fid;
@@ -3656,6 +3722,11 @@ out:
 out_nofid:
     pdu_complete(pdu, err);
     v9fs_string_free(&name);
+#else
+    V9fsPDU *pdu = opaque;
+
+    pdu_complete(pdu, -1);
+#endif
 }
 
 /*
@@ -3928,7 +3999,7 @@ out_nofid:
 #if defined(CONFIG_LINUX)
 /* Currently, only Linux has XATTR_SIZE_MAX */
 #define P9_XATTR_SIZE_MAX XATTR_SIZE_MAX
-#elif defined(CONFIG_DARWIN)
+#elif defined(CONFIG_DARWIN) || defined(CONFIG_WIN32)
 /*
  * Darwin doesn't seem to define a maximum xattr size in its user
  * space header, so manually configure it across platforms as 64k.
@@ -3945,6 +4016,7 @@ out_nofid:
 
 static void coroutine_fn v9fs_xattrcreate(void *opaque)
 {
+#ifndef CONFIG_WIN32
     int flags, rflags = 0;
     int32_t fid;
     uint64_t size;
@@ -4006,10 +4078,15 @@ out_put_fid:
 out_nofid:
     pdu_complete(pdu, err);
     v9fs_string_free(&name);
+#else
+    V9fsPDU *pdu = opaque;
+    pdu_complete(pdu, -1);
+#endif
 }
 
 static void coroutine_fn v9fs_readlink(void *opaque)
 {
+#ifndef CONFIG_WIN32
     V9fsPDU *pdu = opaque;
     size_t offset = 7;
     V9fsString target;
@@ -4045,6 +4122,10 @@ out:
     put_fid(pdu, fidp);
 out_nofid:
     pdu_complete(pdu, err);
+#else
+    V9fsPDU *pdu = opaque;
+    pdu_complete(pdu, -1);
+#endif
 }
 
 static CoroutineEntry *pdu_co_handlers[] = {
@@ -4306,6 +4387,7 @@ void v9fs_reset(V9fsState *s)
 
 static void __attribute__((__constructor__)) v9fs_set_fd_limit(void)
 {
+#ifndef CONFIG_WIN32
     struct rlimit rlim;
     if (getrlimit(RLIMIT_NOFILE, &rlim) < 0) {
         error_report("Failed to get the resource limit");
@@ -4313,4 +4395,5 @@ static void __attribute__((__constructor__)) v9fs_set_fd_limit(void)
     }
     open_fd_hw = rlim.rlim_cur - MIN(400, rlim.rlim_cur / 3);
     open_fd_rc = rlim.rlim_cur / 2;
+#endif
 }
diff --git a/hw/9pfs/codir.c b/hw/9pfs/codir.c
index 93ba44fb75..e75a9892eb 100644
--- a/hw/9pfs/codir.c
+++ b/hw/9pfs/codir.c
@@ -22,7 +22,9 @@
 #include "qemu/coroutine.h"
 #include "qemu/main-loop.h"
 #include "coth.h"
+#ifndef CONFIG_WIN32
 #include "9p-xattr.h"
+#endif
 #include "9p-util.h"
 
 /*
@@ -78,6 +80,9 @@ static int do_readdir_many(V9fsPDU *pdu, V9fsFidState *fidp,
     int len, err = 0;
     int32_t size = 0;
     off_t saved_dir_pos;
+#ifdef CONFIG_WIN32
+    off_t next_dir_pos;
+#endif
     struct dirent *dent;
     struct V9fsDirEnt *e = NULL;
     V9fsPath path;
@@ -124,6 +129,14 @@ static int do_readdir_many(V9fsPDU *pdu, V9fsFidState *fidp,
             break;
         }
 
+#ifdef CONFIG_WIN32
+        next_dir_pos = s->ops->telldir(&s->ctx, &fidp->fs);
+        if (next_dir_pos < 0) {
+            err = next_dir_pos;
+            goto out;
+        }
+#endif
+
         /*
          * stop this loop as soon as it would exceed the allowed maximum
          * response message size for the directory entries collected so far,
@@ -168,7 +181,11 @@ static int do_readdir_many(V9fsPDU *pdu, V9fsFidState *fidp,
         }
 
         size += len;
+#ifndef CONFIG_WIN32
         saved_dir_pos = qemu_dirent_off(dent);
+#else
+        saved_dir_pos = next_dir_pos;
+#endif
     }
 
     /* restore (last) saved position */
diff --git a/hw/9pfs/meson.build b/hw/9pfs/meson.build
index 12443b6ad5..fd15e1fd6b 100644
--- a/hw/9pfs/meson.build
+++ b/hw/9pfs/meson.build
@@ -1,5 +1,13 @@
 fs_ss = ss.source_set()
-fs_ss.add(files(
+fs_ss.add(when: 'CONFIG_WIN32', if_true: files(
+  '9p-local.c',
+  '9p.c',
+  'codir.c',
+  'cofile.c',
+  'cofs.c',
+  'coth.c',
+  'coxattr.c',
+), if_false: files(
   '9p-local.c',
   '9p-posix-acl.c',
   '9p-proxy.c',
-- 
2.25.1

[RFC PATCH 3/4] fsdev: Enable 'local' file system driver backend for Windows

[Bin Meng]

From: Guohuai Shi <guohuai.shi@windriver.com>

Only 'local' file system driver will be supported for Windows host.
'proxy' or 'synth' are not supported.

Signed-off-by: Guohuai Shi <guohuai.shi@windriver.com>
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---

 fsdev/qemu-fsdev.c | 2 ++
 fsdev/meson.build  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
index 3da64e9f72..e1cc677ad8 100644
--- a/fsdev/qemu-fsdev.c
+++ b/fsdev/qemu-fsdev.c
@@ -81,6 +81,7 @@ static FsDriverTable FsDrivers[] = {
             NULL
         },
     },
+#ifndef CONFIG_WIN32
     {
         .name = "synth",
         .ops = &synth_ops,
@@ -100,6 +101,7 @@ static FsDriverTable FsDrivers[] = {
             NULL
         },
     },
+#endif
 };
 
 static int validate_opt(void *opaque, const char *name, const char *value,
diff --git a/fsdev/meson.build b/fsdev/meson.build
index b632b66348..2aad081aef 100644
--- a/fsdev/meson.build
+++ b/fsdev/meson.build
@@ -8,6 +8,7 @@ fsdev_ss.add(when: ['CONFIG_FSDEV_9P'], if_true: files(
 ), if_false: files('qemu-fsdev-dummy.c'))
 softmmu_ss.add_all(when: 'CONFIG_LINUX', if_true: fsdev_ss)
 softmmu_ss.add_all(when: 'CONFIG_DARWIN', if_true: fsdev_ss)
+softmmu_ss.add_all(when: 'CONFIG_WIN32', if_true: fsdev_ss)
 
 if have_virtfs_proxy_helper
   executable('virtfs-proxy-helper',
-- 
2.25.1

[RFC PATCH 4/4] meson.build: Turn on virtfs for Windows host

[Bin Meng]

From: Guohuai Shi <guohuai.shi@windriver.com>

Enable virtfs configuration option for Windows host.

Signed-off-by: Guohuai Shi <guohuai.shi@windriver.com>
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---

 meson.build | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meson.build b/meson.build
index 861de93c4f..a609a9e98f 100644
--- a/meson.build
+++ b/meson.build
@@ -1465,16 +1465,16 @@ dbus_display = get_option('dbus_display') \
   .allowed()
 
 have_virtfs = get_option('virtfs') \
-    .require(targetos == 'linux' or targetos == 'darwin',
-             error_message: 'virtio-9p (virtfs) requires Linux or macOS') \
-    .require(targetos == 'linux' or cc.has_function('pthread_fchdir_np'),
+    .require(targetos == 'linux' or targetos == 'darwin' or targetos == 'windows',
+             error_message: 'virtio-9p (virtfs) requires Linux or macOS or Windows') \
+    .require(targetos == 'linux' or cc.has_function('pthread_fchdir_np') or targetos == 'windows',
              error_message: 'virtio-9p (virtfs) on macOS requires the presence of pthread_fchdir_np') \
-    .require(targetos == 'darwin' or (libattr.found() and libcap_ng.found()),
+    .require(targetos == 'darwin' or (libattr.found() and libcap_ng.found()) or targetos == 'windows',
              error_message: 'virtio-9p (virtfs) on Linux requires libcap-ng-devel and libattr-devel') \
     .disable_auto_if(not have_tools and not have_system) \
     .allowed()
 
-have_virtfs_proxy_helper = targetos != 'darwin' and have_virtfs and have_tools
+have_virtfs_proxy_helper = targetos != 'darwin' and targetos != 'windows' and have_virtfs and have_tools
 
 foreach k : get_option('trace_backends')
   config_host_data.set('CONFIG_TRACE_' + k.to_upper(), true)
-- 
2.25.1

Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Christian Schoenebeck]

On Freitag, 8. April 2022 19:10:09 CEST Bin Meng wrote:
> At present there is no Windows support for 9p file system.
> This series adds initial Windows support for 9p file system.

Nice!

> Only 'local' file system driver backend is supported. security_model
> should be 'none' due to limitations on Windows host.

We have 3 fs drivers: local, synth, proxy. I don't mind about proxy, it is in 
bad shape and we will probably deprecate it in near future anyway. But it 
would be good to have support for the synth driver, because we are using it 
for running test cases and fuzzing tests (QA).

What are the limitations against security_model=mapped on Windows? Keep in 
mind that with security_model=none you are very limited in what you can do 
with 9p.

> Example command line to test:
> 
>   "-fsdev local,path=c:\msys64,security_model=none,id=p9 -device
> virtio-9p-pci,fsdev=p9,mount_tag=p9fs"
> 
> 
> Guohuai Shi (4):
>   fsdev: Add missing definitions for Windows in file-op-9p.h
>   hw/9pfs: Update 'local' file system backend driver to support Windows
>   fsdev: Enable 'local' file system driver backend for Windows
>   meson.build: Turn on virtfs for Windows host
> 
>  meson.build         |  10 +-
>  fsdev/file-op-9p.h  |  33 ++++++
>  hw/9pfs/9p-util.h   |   4 +
>  hw/9pfs/9p.h        |  22 ++++
>  fsdev/qemu-fsdev.c  |   2 +
>  hw/9pfs/9p-local.c  | 273 +++++++++++++++++++++++++++++++++++++++++++-
>  hw/9pfs/9p.c        |  85 +++++++++++++-
>  hw/9pfs/codir.c     |  17 +++
>  fsdev/meson.build   |   1 +
>  hw/9pfs/meson.build |  10 +-
>  10 files changed, 449 insertions(+), 8 deletions(-)

Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Bin Meng]

+Guohuai

On Tue, Apr 12, 2022 at 8:27 PM Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
>
> On Freitag, 8. April 2022 19:10:09 CEST Bin Meng wrote:
> > At present there is no Windows support for 9p file system.
> > This series adds initial Windows support for 9p file system.
>
> Nice!
>
> > Only 'local' file system driver backend is supported. security_model
> > should be 'none' due to limitations on Windows host.
>
> We have 3 fs drivers: local, synth, proxy. I don't mind about proxy, it is in
> bad shape and we will probably deprecate it in near future anyway. But it
> would be good to have support for the synth driver, because we are using it
> for running test cases and fuzzing tests (QA).
>
> What are the limitations against security_model=mapped on Windows? Keep in
> mind that with security_model=none you are very limited in what you can do
> with 9p.
>

Regards,
Bin

RE: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Shi, Guohuai]

> We have 3 fs drivers: local, synth, proxy. I don't mind about proxy, it is in 
> bad shape and we will probably deprecate it in near future anyway. But it 
> would be good to have support for the synth driver, because we are using it 
> for running test cases and fuzzing tests (QA).

synth driver can not be built on Windows platform (or cross build on Linux).
So the test cases can not work on Windows.

> What are the limitations against security_model=mapped on Windows? Keep in 
> mind that with security_model=none you are very limited in what you can do 
> with 9p.

MSYS library does not support extend attribute (e.g. getxattr),
And does not support POSIX permission APIs (e.g. chmod, chown).
Security model is useless on Windows host.

It is possible that to "map" extend attribute to NTFS stream data.
However, if Windows host media is not NTFS (e.g. FAT) which does not support stream data,
then the "map" can not work.

Thanks
Guohuai


-----Original Message-----
From: Bin Meng <bmeng.cn@gmail.com> 
Sent: 2022年4月13日 11:19
To: Christian Schoenebeck <qemu_oss@crudebyte.com>; Shi, Guohuai <Guohuai.Shi@windriver.com>
Cc: qemu-devel@nongnu.org Developers <qemu-devel@nongnu.org>; Greg Kurz <groug@kaod.org>
Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Please note: This e-mail is from an EXTERNAL e-mail address]

+Guohuai

On Tue, Apr 12, 2022 at 8:27 PM Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
>
> On Freitag, 8. April 2022 19:10:09 CEST Bin Meng wrote:
> > At present there is no Windows support for 9p file system.
> > This series adds initial Windows support for 9p file system.
>
> Nice!
>
> > Only 'local' file system driver backend is supported. security_model 
> > should be 'none' due to limitations on Windows host.
>
> We have 3 fs drivers: local, synth, proxy. I don't mind about proxy, 
> it is in bad shape and we will probably deprecate it in near future 
> anyway. But it would be good to have support for the synth driver, 
> because we are using it for running test cases and fuzzing tests (QA).
>
> What are the limitations against security_model=mapped on Windows? 
> Keep in mind that with security_model=none you are very limited in 
> what you can do with 9p.
>

Regards,
Bin

Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Christian Schoenebeck]

On Mittwoch, 13. April 2022 05:30:57 CEST Shi, Guohuai wrote:
> > We have 3 fs drivers: local, synth, proxy. I don't mind about proxy, it is
> > in  bad shape and we will probably deprecate it in near future anyway.
> > But it would be good to have support for the synth driver, because we are
> > using it for running test cases and fuzzing tests (QA).
> 
> synth driver can not be built on Windows platform (or cross build on
> Linux). So the test cases can not work on Windows.

Could you please be more specific what kind of challenge you see for making 
the synth driver working on Windows? The synth driver is just a simple mockup 
driver [1] that simulates in-RAM-only a filesystem with a bunch of hard coded 
dirs and files, solely for the purpose to run test cases. So the synth driver 
does not interact with any real filesystem on host at all. My expectation 
therefore would be that it just needs to tweak some header includes and maybe 
declaring missing POSIX data types, which you have done for the local driver 
already anyway.

BTW support for macOS hosts has just been recently added for 9p, I know it is 
different as its a POSIX OS, but maybe you might still find the diff [2] 
helpful.

[1] https://wiki.qemu.org/Documentation/9p#9p_Filesystem_Drivers
[2] https://gitlab.com/qemu-project/qemu/-/commit/f45cc81911adc772

> > What are the limitations against security_model=mapped on Windows? Keep in
> >  mind that with security_model=none you are very limited in what you can
> > do with 9p.
> 
> MSYS library does not support extend attribute (e.g. getxattr),
> And does not support POSIX permission APIs (e.g. chmod, chown).
> Security model is useless on Windows host.

That would be security_model=passthrough, yes, that's not possible with msys. 
The recommended way in practice though is using security_model=mapped [3] for 
all systems, which should be possible to achieve with msys as well ...

[3] https://wiki.qemu.org/Documentation/9psetup#Starting_the_Guest_directly

> It is possible that to "map" extend attribute to NTFS stream data.
> However, if Windows host media is not NTFS (e.g. FAT) which does not support
> stream data, then the "map" can not work.

... yes exactly, it would make sense to use ADS [4] instead of xattr on 
Windows. ADS are available with NTFS and ReFS and maybe also with exFAT 
nowadays (?), not sure about the latter though. But I think it is fair enough 
to assume Windows users to either use NTFS or ReFS. And if they don't, you can 
still call error_report_once() to make user aware that
seucrity_model=mapped(-xattr) requires a fileystem on Windows that supports 
ADS.

[4] https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)

Best regards,
Christian Schoenebeck

RE: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Shi, Guohuai]

> -----Original Message-----
> From: Christian Schoenebeck <qemu_oss@crudebyte.com>
> Sent: 2022年4月14日 19:24
> To: qemu-devel@nongnu.org; Shi, Guohuai <Guohuai.Shi@windriver.com>
> Cc: Bin Meng <bmeng.cn@gmail.com>; Greg Kurz <groug@kaod.org>
> Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host
> 
> [Please note: This e-mail is from an EXTERNAL e-mail address]
> 
> On Mittwoch, 13. April 2022 05:30:57 CEST Shi, Guohuai wrote:
> > > We have 3 fs drivers: local, synth, proxy. I don't mind about proxy,
> > > it is in  bad shape and we will probably deprecate it in near future anyway.
> > > But it would be good to have support for the synth driver, because
> > > we are using it for running test cases and fuzzing tests (QA).
> >
> > synth driver can not be built on Windows platform (or cross build on
> > Linux). So the test cases can not work on Windows.
> 
> Could you please be more specific what kind of challenge you see for making the
> synth driver working on Windows? The synth driver is just a simple mockup driver
> [1] that simulates in-RAM-only a filesystem with a bunch of hard coded dirs and
> files, solely for the purpose to run test cases. So the synth driver does not interact
> with any real filesystem on host at all. My expectation therefore would be that
> it just needs to tweak some header includes and maybe declaring missing POSIX data
> types, which you have done for the local driver already anyway.
> 

For 9p-synth:

I had enabled 9p-synth.c and built it successfully on Windows platform.
However, test cases code are not built on Windows host.
So I think it is useless that enable synth on Windows host (no way to run it).

> BTW support for macOS hosts has just been recently added for 9p, I know it is
> different as its a POSIX OS, but maybe you might still find the diff [2] helpful.
> 
> [1] https://wiki.qemu.org/Documentation/9p#9p_Filesystem_Drivers
> [2] https://gitlab.com/qemu-project/qemu/-/commit/f45cc81911adc772
> 
> > > What are the limitations against security_model=mapped on Windows?
> > > Keep in  mind that with security_model=none you are very limited in
> > > what you can do with 9p.
> >
> > MSYS library does not support extend attribute (e.g. getxattr), And
> > does not support POSIX permission APIs (e.g. chmod, chown).
> > Security model is useless on Windows host.
> 
> That would be security_model=passthrough, yes, that's not possible with msys.
> The recommended way in practice though is using security_model=mapped [3] for all
> systems, which should be possible to achieve with msys as well ...
> 
> [3] https://wiki.qemu.org/Documentation/9psetup#Starting_the_Guest_directly
> 
> > It is possible that to "map" extend attribute to NTFS stream data.
> > However, if Windows host media is not NTFS (e.g. FAT) which does not
> > support stream data, then the "map" can not work.
> 
> ... yes exactly, it would make sense to use ADS [4] instead of xattr on Windows.
> ADS are available with NTFS and ReFS and maybe also with exFAT nowadays (?), not
> sure about the latter though. But I think it is fair enough to assume Windows users
> to either use NTFS or ReFS. And if they don't, you can still call error_report_once()
> to make user aware that
> seucrity_model=mapped(-xattr) requires a fileystem on Windows that supports ADS.
> 
> [4] https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)
> 

Windows does not support POSIX permission. 
So I think that only allow user to use security_model=none is reasonable on Windows host.

There is a difficulty to support "mapped" or "mapped-file" on Windows host:
There are many functions in 9p-code using APIs like "openat", "mkdirat", etc.
MSYS does not support that (openat is not valid on Windows host).
I remember that 9p replaced "open" by "openat" for a long time.
To fully support "security_model=mapped", 9p for Windows need to replace "openat" by "open".
This may impact too many functions.

I would have a try to enable "mapped" by using ADS, but it looks like a big refactor for 9p-local.c

Best Regards,
Guohuai 

Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Christian Schoenebeck]

On Donnerstag, 14. April 2022 19:25:04 CEST Shi, Guohuai wrote:
> > -----Original Message-----
> > From: Christian Schoenebeck <qemu_oss@crudebyte.com>
> > Sent: 2022年4月14日 19:24
> > To: qemu-devel@nongnu.org; Shi, Guohuai <Guohuai.Shi@windriver.com>
> > Cc: Bin Meng <bmeng.cn@gmail.com>; Greg Kurz <groug@kaod.org>
> > Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host
> > 
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> > 
> > On Mittwoch, 13. April 2022 05:30:57 CEST Shi, Guohuai wrote:
> > 
> > > > We have 3 fs drivers: local, synth, proxy. I don't mind about proxy,
> > > > it is in  bad shape and we will probably deprecate it in near future
> > > > anyway. But it would be good to have support for the synth driver,
> > > > because we are using it for running test cases and fuzzing tests
> > > > (QA).
[...]
> For 9p-synth:
> 
> I had enabled 9p-synth.c and built it successfully on Windows platform.
> However, test cases code are not built on Windows host.
> So I think it is useless that enable synth on Windows host (no way to run
> it).

Please, don't give up too soon. Looking at tests/qtest/meson.build it starts 
with:

# All QTests for now are POSIX-only, but the dependencies are
# really in libqtest, not in the testcases themselves.
if not config_host.has_key('CONFIG_POSIX')
  subdir_done()
endif

And looking at tests/qtest/libqtest.c I "think" this should be working on 
Windows as well. It uses socket APIs which are available on Windows. I don't 
see a real show stopper here for Windows.

Could you please try if you can compile the tests on Windows? What we would 
need is test/qtest/qos-test, we don't need all the other tests:

https://wiki.qemu.org/Documentation/9p#Test_Cases

> > > It is possible that to "map" extend attribute to NTFS stream data.
> > > However, if Windows host media is not NTFS (e.g. FAT) which does not
> > > support stream data, then the "map" can not work.
> > 
> > ... yes exactly, it would make sense to use ADS [4] instead of xattr on
> > Windows. ADS are available with NTFS and ReFS and maybe also with exFAT
> > nowadays (?), not sure about the latter though. But I think it is fair
> > enough to assume Windows users to either use NTFS or ReFS. And if they
> > don't, you can still call error_report_once() to make user aware that
> > seucrity_model=mapped(-xattr) requires a fileystem on Windows that
> > supports ADS.
> > [4] https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)
> > 
> 
> Windows does not support POSIX permission. 
> So I think that only allow user to use security_model=none is reasonable on
> Windows host.

It depends on the use case. I assume your use case are Windows guests, in that 
case you don't have the concept of POSIX permissions neither on guest side, 
nor on host side (on the long-term I am pretty sure though that Windows guest 
users would want to have some kind of Windows ACL mapping implementation as 
well).

> There is a difficulty to support "mapped" or "mapped-file" on Windows host:
> There are many functions in 9p-code using APIs like "openat", "mkdirat",
> etc. MSYS does not support that (openat is not valid on Windows host). I
> remember that 9p replaced "open" by "openat" for a long time.
> To fully support "security_model=mapped", 9p for Windows need to replace
> "openat" by "open". This may impact too many functions.
> 
> I would have a try to enable "mapped" by using ADS, but it looks like a big
> refactor for 9p-local.c

Regarding openat(): We had a similar challenge for macOS host implementation; 
macOS does not have mknodat(), so what we're currently doing is

  pthread_fchdir_np(...)
  mknod(...)

  https://github.com/qemu/qemu/blob/master/hw/9pfs/9p-util-darwin.c#L84

So on Windows you could do:

  chdir(...)
  open(...)

as workaround for providing openat() for msys.

For security_model=mapped(-xattr) to work on Windows you basically would need 
to provide a replacement implementation (based on Windows ADS) in
9p-util-windows.c for:

  ssize_t fgetxattrat_nofollow(int dirfd, const char *filename, const char   
                               *name, void *value, size_t size);

  ssize_t flistxattrat_nofollow(int dirfd, const char *filename,
                                char *list, size_t size);

  ssize_t fremovexattrat_nofollow(int dirfd, const char *filename,
                                  const char *name);

  int fsetxattrat_nofollow(int dirfd, const char *filename, const char *name,
                           void *value, size_t size, int flags);

So it does not look too bad I think to get security_model=mapped working, and 
it would make Windows 9p host support much more usable (for Linux guests, 
macOS guests, but also for Windows guests with mapped Windows ACL in future).

Best regards,
Christian Schoenebeck

Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Mark Cave-Ayland]

On 17/04/2022 13:55, Christian Schoenebeck wrote:

> On Donnerstag, 14. April 2022 19:25:04 CEST Shi, Guohuai wrote:
>>> -----Original Message-----
>>> From: Christian Schoenebeck <qemu_oss@crudebyte.com>
>>> Sent: 2022年4月14日 19:24
>>> To: qemu-devel@nongnu.org; Shi, Guohuai <Guohuai.Shi@windriver.com>
>>> Cc: Bin Meng <bmeng.cn@gmail.com>; Greg Kurz <groug@kaod.org>
>>> Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host
>>>
>>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>>>
>>> On Mittwoch, 13. April 2022 05:30:57 CEST Shi, Guohuai wrote:
>>>
>>>>> We have 3 fs drivers: local, synth, proxy. I don't mind about proxy,
>>>>> it is in  bad shape and we will probably deprecate it in near future
>>>>> anyway. But it would be good to have support for the synth driver,
>>>>> because we are using it for running test cases and fuzzing tests
>>>>> (QA).
> [...]
>> For 9p-synth:
>>
>> I had enabled 9p-synth.c and built it successfully on Windows platform.
>> However, test cases code are not built on Windows host.
>> So I think it is useless that enable synth on Windows host (no way to run
>> it).
> 
> Please, don't give up too soon. Looking at tests/qtest/meson.build it starts
> with:
> 
> # All QTests for now are POSIX-only, but the dependencies are
> # really in libqtest, not in the testcases themselves.
> if not config_host.has_key('CONFIG_POSIX')
>    subdir_done()
> endif
> 
> And looking at tests/qtest/libqtest.c I "think" this should be working on
> Windows as well. It uses socket APIs which are available on Windows. I don't
> see a real show stopper here for Windows.
> 
> Could you please try if you can compile the tests on Windows? What we would
> need is test/qtest/qos-test, we don't need all the other tests:
> 
> https://wiki.qemu.org/Documentation/9p#Test_Cases
> 
>>>> It is possible that to "map" extend attribute to NTFS stream data.
>>>> However, if Windows host media is not NTFS (e.g. FAT) which does not
>>>> support stream data, then the "map" can not work.
>>>
>>> ... yes exactly, it would make sense to use ADS [4] instead of xattr on
>>> Windows. ADS are available with NTFS and ReFS and maybe also with exFAT
>>> nowadays (?), not sure about the latter though. But I think it is fair
>>> enough to assume Windows users to either use NTFS or ReFS. And if they
>>> don't, you can still call error_report_once() to make user aware that
>>> seucrity_model=mapped(-xattr) requires a fileystem on Windows that
>>> supports ADS.
>>> [4] https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)
>>>
>>
>> Windows does not support POSIX permission.
>> So I think that only allow user to use security_model=none is reasonable on
>> Windows host.
> 
> It depends on the use case. I assume your use case are Windows guests, in that
> case you don't have the concept of POSIX permissions neither on guest side,
> nor on host side (on the long-term I am pretty sure though that Windows guest
> users would want to have some kind of Windows ACL mapping implementation as
> well).
> 
>> There is a difficulty to support "mapped" or "mapped-file" on Windows host:
>> There are many functions in 9p-code using APIs like "openat", "mkdirat",
>> etc. MSYS does not support that (openat is not valid on Windows host). I
>> remember that 9p replaced "open" by "openat" for a long time.
>> To fully support "security_model=mapped", 9p for Windows need to replace
>> "openat" by "open". This may impact too many functions.
>>
>> I would have a try to enable "mapped" by using ADS, but it looks like a big
>> refactor for 9p-local.c
> 
> Regarding openat(): We had a similar challenge for macOS host implementation;
> macOS does not have mknodat(), so what we're currently doing is
> 
>    pthread_fchdir_np(...)
>    mknod(...)
> 
>    https://github.com/qemu/qemu/blob/master/hw/9pfs/9p-util-darwin.c#L84
> 
> So on Windows you could do:
> 
>    chdir(...)
>    open(...)
> 
> as workaround for providing openat() for msys.
> 
> For security_model=mapped(-xattr) to work on Windows you basically would need
> to provide a replacement implementation (based on Windows ADS) in
> 9p-util-windows.c for:
> 
>    ssize_t fgetxattrat_nofollow(int dirfd, const char *filename, const char
>                                 *name, void *value, size_t size);
> 
>    ssize_t flistxattrat_nofollow(int dirfd, const char *filename,
>                                  char *list, size_t size);
> 
>    ssize_t fremovexattrat_nofollow(int dirfd, const char *filename,
>                                    const char *name);
> 
>    int fsetxattrat_nofollow(int dirfd, const char *filename, const char *name,
>                             void *value, size_t size, int flags);
> 
> So it does not look too bad I think to get security_model=mapped working, and
> it would make Windows 9p host support much more usable (for Linux guests,
> macOS guests, but also for Windows guests with mapped Windows ACL in future).

FWIW even just having security_model=none would be very useful here, since then 9pfs 
could be used to share host files across all of Windows, MacOS and POSIX OSs which is 
something that can't yet be done with virtiofsd.

Whilst using ADS would allow the xattrs to be attached to files, how would this work 
in the case of ACLs which are stored as a "system.posix_acl_access" attribute? My 
concern would be that files copied from the guest to the host wouldn't have sensible 
permissions when read directly on the host. Presumably there would be some existing 
precedent for how this is handled in WSL2?


ATB,

Mark.

Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Christian Schoenebeck]

On Montag, 18. April 2022 11:07:33 CEST Mark Cave-Ayland wrote:
> On 17/04/2022 13:55, Christian Schoenebeck wrote:
> > On Donnerstag, 14. April 2022 19:25:04 CEST Shi, Guohuai wrote:
> >>> -----Original Message-----
> >>> From: Christian Schoenebeck <qemu_oss@crudebyte.com>
> >>> Sent: 2022年4月14日 19:24
> >>> To: qemu-devel@nongnu.org; Shi, Guohuai <Guohuai.Shi@windriver.com>
> >>> Cc: Bin Meng <bmeng.cn@gmail.com>; Greg Kurz <groug@kaod.org>
> >>> Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host
> >>> 
> >>> [Please note: This e-mail is from an EXTERNAL e-mail address]
> >>> 
> >>> On Mittwoch, 13. April 2022 05:30:57 CEST Shi, Guohuai wrote:
> >>>>> We have 3 fs drivers: local, synth, proxy. I don't mind about proxy,
> >>>>> it is in  bad shape and we will probably deprecate it in near future
> >>>>> anyway. But it would be good to have support for the synth driver,
> >>>>> because we are using it for running test cases and fuzzing tests
> >>>>> (QA).
> > 
> > [...]
> > 
> >> For 9p-synth:
> >> 
> >> I had enabled 9p-synth.c and built it successfully on Windows platform.
> >> However, test cases code are not built on Windows host.
> >> So I think it is useless that enable synth on Windows host (no way to run
> >> it).
> > 
> > Please, don't give up too soon. Looking at tests/qtest/meson.build it
> > starts with:
> > 
> > # All QTests for now are POSIX-only, but the dependencies are
> > # really in libqtest, not in the testcases themselves.
> > if not config_host.has_key('CONFIG_POSIX')
> > 
> >    subdir_done()
> > 
> > endif
> > 
> > And looking at tests/qtest/libqtest.c I "think" this should be working on
> > Windows as well. It uses socket APIs which are available on Windows. I
> > don't see a real show stopper here for Windows.
> > 
> > Could you please try if you can compile the tests on Windows? What we
> > would
> > need is test/qtest/qos-test, we don't need all the other tests:
> > 
> > https://wiki.qemu.org/Documentation/9p#Test_Cases
> > 
> >>>> It is possible that to "map" extend attribute to NTFS stream data.
> >>>> However, if Windows host media is not NTFS (e.g. FAT) which does not
> >>>> support stream data, then the "map" can not work.
> >>> 
> >>> ... yes exactly, it would make sense to use ADS [4] instead of xattr on
> >>> Windows. ADS are available with NTFS and ReFS and maybe also with exFAT
> >>> nowadays (?), not sure about the latter though. But I think it is fair
> >>> enough to assume Windows users to either use NTFS or ReFS. And if they
> >>> don't, you can still call error_report_once() to make user aware that
> >>> seucrity_model=mapped(-xattr) requires a fileystem on Windows that
> >>> supports ADS.
> >>> [4] https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)
> >> 
> >> Windows does not support POSIX permission.
> >> So I think that only allow user to use security_model=none is reasonable
> >> on
> >> Windows host.
> > 
> > It depends on the use case. I assume your use case are Windows guests, in
> > that case you don't have the concept of POSIX permissions neither on
> > guest side, nor on host side (on the long-term I am pretty sure though
> > that Windows guest users would want to have some kind of Windows ACL
> > mapping implementation as well).
> > 
> >> There is a difficulty to support "mapped" or "mapped-file" on Windows
> >> host:
> >> There are many functions in 9p-code using APIs like "openat", "mkdirat",
> >> etc. MSYS does not support that (openat is not valid on Windows host). I
> >> remember that 9p replaced "open" by "openat" for a long time.
> >> To fully support "security_model=mapped", 9p for Windows need to replace
> >> "openat" by "open". This may impact too many functions.
> >> 
> >> I would have a try to enable "mapped" by using ADS, but it looks like a
> >> big
> >> refactor for 9p-local.c
> > 
> > Regarding openat(): We had a similar challenge for macOS host
> > implementation; macOS does not have mknodat(), so what we're currently
> > doing is
> > 
> >    pthread_fchdir_np(...)
> >    mknod(...)
> >    
> >    https://github.com/qemu/qemu/blob/master/hw/9pfs/9p-util-darwin.c#L84
> > 
> > So on Windows you could do:
> >    chdir(...)
> >    open(...)
> > 
> > as workaround for providing openat() for msys.
> > 
> > For security_model=mapped(-xattr) to work on Windows you basically would
> > need to provide a replacement implementation (based on Windows ADS) in
> > 
> > 9p-util-windows.c for:
> >    ssize_t fgetxattrat_nofollow(int dirfd, const char *filename, const
> >    char
> >    
> >                                 *name, void *value, size_t size);
> >    
> >    ssize_t flistxattrat_nofollow(int dirfd, const char *filename,
> >    
> >                                  char *list, size_t size);
> >    
> >    ssize_t fremovexattrat_nofollow(int dirfd, const char *filename,
> >    
> >                                    const char *name);
> >    
> >    int fsetxattrat_nofollow(int dirfd, const char *filename, const char
> >    *name,
> >    
> >                             void *value, size_t size, int flags);
> > 
> > So it does not look too bad I think to get security_model=mapped working,
> > and it would make Windows 9p host support much more usable (for Linux
> > guests, macOS guests, but also for Windows guests with mapped Windows ACL
> > in future).
> FWIW even just having security_model=none would be very useful here, since
> then 9pfs could be used to share host files across all of Windows, MacOS
> and POSIX OSs which is something that can't yet be done with virtiofsd.
> 
> Whilst using ADS would allow the xattrs to be attached to files, how would
> this work in the case of ACLs which are stored as a
> "system.posix_acl_access" attribute? My concern would be that files copied
> from the guest to the host wouldn't have sensible permissions when read
> directly on the host. Presumably there would be some existing precedent for
> how this is handled in WSL2?

The behaviour with security_level=mapped on Windows would be identical to that 
of other already supported systems, that is there are two *distinct* levels 
for ownership and permissions in mapped mode:

1. The actual ownership information and permissions on host's file system. 
Guest won't ever get more permissions than those on host fs level, so this 
level defines the maximum permissions if you will. Those information are not 
directly exposed to, visible to, nor altered by guest though.

2. The ownership information and permissions mapped by 9p server. That's what 
guest sees and is able to alter in this mode. The only difference between 
security_level=mapped(-xattr) and security_level=mapped-file is just the 
location where those mapped ownership and permissions are stored to by 9p 
server (currently: either hidden xattr vs. hidden file).

See also section "1. local fs driver" for some more explanation on this:
https://wiki.qemu.org/Documentation/9p#9p_Filesystem_Drivers

As for POSIX ACLs specifically: a Linux guest kernel does access those as 
"system.posix_acl_access" and "system.posix_acl_default" xattrs, but on host 
fs level they are actually stored and read by 9p server as 
"user.virtfs.posix_acl_access" and "user.virtfs.posix_acl_default" xattrs 
instead. So again, ACLs that may exist on host fs level are separated from 
ACLs on guest level in mapped mode, similar to POSIX ownership, permissions 
and device type info.

Best regards,
Christian Schoenebeck

Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Mark Cave-Ayland]

On 18/04/2022 13:31, Christian Schoenebeck wrote:

> On Montag, 18. April 2022 11:07:33 CEST Mark Cave-Ayland wrote:
>> On 17/04/2022 13:55, Christian Schoenebeck wrote:
>>> On Donnerstag, 14. April 2022 19:25:04 CEST Shi, Guohuai wrote:
>>>>> -----Original Message-----
>>>>> From: Christian Schoenebeck <qemu_oss@crudebyte.com>
>>>>> Sent: 2022年4月14日 19:24
>>>>> To: qemu-devel@nongnu.org; Shi, Guohuai <Guohuai.Shi@windriver.com>
>>>>> Cc: Bin Meng <bmeng.cn@gmail.com>; Greg Kurz <groug@kaod.org>
>>>>> Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host
>>>>>
>>>>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>>>>>
>>>>> On Mittwoch, 13. April 2022 05:30:57 CEST Shi, Guohuai wrote:
>>>>>>> We have 3 fs drivers: local, synth, proxy. I don't mind about proxy,
>>>>>>> it is in  bad shape and we will probably deprecate it in near future
>>>>>>> anyway. But it would be good to have support for the synth driver,
>>>>>>> because we are using it for running test cases and fuzzing tests
>>>>>>> (QA).
>>>
>>> [...]
>>>
>>>> For 9p-synth:
>>>>
>>>> I had enabled 9p-synth.c and built it successfully on Windows platform.
>>>> However, test cases code are not built on Windows host.
>>>> So I think it is useless that enable synth on Windows host (no way to run
>>>> it).
>>>
>>> Please, don't give up too soon. Looking at tests/qtest/meson.build it
>>> starts with:
>>>
>>> # All QTests for now are POSIX-only, but the dependencies are
>>> # really in libqtest, not in the testcases themselves.
>>> if not config_host.has_key('CONFIG_POSIX')
>>>
>>>     subdir_done()
>>>
>>> endif
>>>
>>> And looking at tests/qtest/libqtest.c I "think" this should be working on
>>> Windows as well. It uses socket APIs which are available on Windows. I
>>> don't see a real show stopper here for Windows.
>>>
>>> Could you please try if you can compile the tests on Windows? What we
>>> would
>>> need is test/qtest/qos-test, we don't need all the other tests:
>>>
>>> https://wiki.qemu.org/Documentation/9p#Test_Cases
>>>
>>>>>> It is possible that to "map" extend attribute to NTFS stream data.
>>>>>> However, if Windows host media is not NTFS (e.g. FAT) which does not
>>>>>> support stream data, then the "map" can not work.
>>>>>
>>>>> ... yes exactly, it would make sense to use ADS [4] instead of xattr on
>>>>> Windows. ADS are available with NTFS and ReFS and maybe also with exFAT
>>>>> nowadays (?), not sure about the latter though. But I think it is fair
>>>>> enough to assume Windows users to either use NTFS or ReFS. And if they
>>>>> don't, you can still call error_report_once() to make user aware that
>>>>> seucrity_model=mapped(-xattr) requires a fileystem on Windows that
>>>>> supports ADS.
>>>>> [4] https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)
>>>>
>>>> Windows does not support POSIX permission.
>>>> So I think that only allow user to use security_model=none is reasonable
>>>> on
>>>> Windows host.
>>>
>>> It depends on the use case. I assume your use case are Windows guests, in
>>> that case you don't have the concept of POSIX permissions neither on
>>> guest side, nor on host side (on the long-term I am pretty sure though
>>> that Windows guest users would want to have some kind of Windows ACL
>>> mapping implementation as well).
>>>
>>>> There is a difficulty to support "mapped" or "mapped-file" on Windows
>>>> host:
>>>> There are many functions in 9p-code using APIs like "openat", "mkdirat",
>>>> etc. MSYS does not support that (openat is not valid on Windows host). I
>>>> remember that 9p replaced "open" by "openat" for a long time.
>>>> To fully support "security_model=mapped", 9p for Windows need to replace
>>>> "openat" by "open". This may impact too many functions.
>>>>
>>>> I would have a try to enable "mapped" by using ADS, but it looks like a
>>>> big
>>>> refactor for 9p-local.c
>>>
>>> Regarding openat(): We had a similar challenge for macOS host
>>> implementation; macOS does not have mknodat(), so what we're currently
>>> doing is
>>>
>>>     pthread_fchdir_np(...)
>>>     mknod(...)
>>>     
>>>     https://github.com/qemu/qemu/blob/master/hw/9pfs/9p-util-darwin.c#L84
>>>
>>> So on Windows you could do:
>>>     chdir(...)
>>>     open(...)
>>>
>>> as workaround for providing openat() for msys.
>>>
>>> For security_model=mapped(-xattr) to work on Windows you basically would
>>> need to provide a replacement implementation (based on Windows ADS) in
>>>
>>> 9p-util-windows.c for:
>>>     ssize_t fgetxattrat_nofollow(int dirfd, const char *filename, const
>>>     char
>>>     
>>>                                  *name, void *value, size_t size);
>>>     
>>>     ssize_t flistxattrat_nofollow(int dirfd, const char *filename,
>>>     
>>>                                   char *list, size_t size);
>>>     
>>>     ssize_t fremovexattrat_nofollow(int dirfd, const char *filename,
>>>     
>>>                                     const char *name);
>>>     
>>>     int fsetxattrat_nofollow(int dirfd, const char *filename, const char
>>>     *name,
>>>     
>>>                              void *value, size_t size, int flags);
>>>
>>> So it does not look too bad I think to get security_model=mapped working,
>>> and it would make Windows 9p host support much more usable (for Linux
>>> guests, macOS guests, but also for Windows guests with mapped Windows ACL
>>> in future).
>> FWIW even just having security_model=none would be very useful here, since
>> then 9pfs could be used to share host files across all of Windows, MacOS
>> and POSIX OSs which is something that can't yet be done with virtiofsd.
>>
>> Whilst using ADS would allow the xattrs to be attached to files, how would
>> this work in the case of ACLs which are stored as a
>> "system.posix_acl_access" attribute? My concern would be that files copied
>> from the guest to the host wouldn't have sensible permissions when read
>> directly on the host. Presumably there would be some existing precedent for
>> how this is handled in WSL2?
> 
> The behaviour with security_level=mapped on Windows would be identical to that
> of other already supported systems, that is there are two *distinct* levels
> for ownership and permissions in mapped mode:
> 
> 1. The actual ownership information and permissions on host's file system.
> Guest won't ever get more permissions than those on host fs level, so this
> level defines the maximum permissions if you will. Those information are not
> directly exposed to, visible to, nor altered by guest though.
> 
> 2. The ownership information and permissions mapped by 9p server. That's what
> guest sees and is able to alter in this mode. The only difference between
> security_level=mapped(-xattr) and security_level=mapped-file is just the
> location where those mapped ownership and permissions are stored to by 9p
> server (currently: either hidden xattr vs. hidden file).
> 
> See also section "1. local fs driver" for some more explanation on this:
> https://wiki.qemu.org/Documentation/9p#9p_Filesystem_Drivers
> 
> As for POSIX ACLs specifically: a Linux guest kernel does access those as
> "system.posix_acl_access" and "system.posix_acl_default" xattrs, but on host
> fs level they are actually stored and read by 9p server as
> "user.virtfs.posix_acl_access" and "user.virtfs.posix_acl_default" xattrs
> instead. So again, ACLs that may exist on host fs level are separated from
> ACLs on guest level in mapped mode, similar to POSIX ownership, permissions
> and device type info.

Hi Christian,

Thanks for the detailed explanation, the last paragraph above in particular clearly 
answers my question as to how 9pfs handles the xattr-based permissions in mapped mode.

I am certainly interested to help test later versions of the patchset.


ATB,

Mark.

RE: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Shi, Guohuai]

Hi All,

I just finished a basic PoC for mapped-file.
It works! I think I can also support "security_model=map-xattr" by NTFS ADS.

However, I got a limitation of MinGW:

https://github.com/mirror/mingw-w64/blob/master/mingw-w64-crt/misc/dirent.c#L290

MinGW can not handle seekdir() while the directory has changed.
That means, if run command like "rm -rf *", MinGW may not delete all files.
"rm -rf *" need to call readdir()(and call seekdir() in 9P) and unlink(), 
and MinGW's seekdir() may seek directory to wrong directory entry index.

I am considering to change 9PFS readdir() implement on Windows host, to fix this problem.

Thanks,
Guohuai

-----Original Message-----
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> 
Sent: Tuesday, April 19, 2022 18:59
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: Shi, Guohuai <Guohuai.Shi@windriver.com>; qemu-devel@nongnu.org; Bin Meng <bmeng.cn@gmail.com>; Greg Kurz <groug@kaod.org>
Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Please note: This e-mail is from an EXTERNAL e-mail address]

On 18/04/2022 13:31, Christian Schoenebeck wrote:

> On Montag, 18. April 2022 11:07:33 CEST Mark Cave-Ayland wrote:
>> On 17/04/2022 13:55, Christian Schoenebeck wrote:
>>> On Donnerstag, 14. April 2022 19:25:04 CEST Shi, Guohuai wrote:
>>>>> -----Original Message-----
>>>>> From: Christian Schoenebeck <qemu_oss@crudebyte.com>
>>>>> Sent: 2022年4月14日 19:24
>>>>> To: qemu-devel@nongnu.org; Shi, Guohuai 
>>>>> <Guohuai.Shi@windriver.com>
>>>>> Cc: Bin Meng <bmeng.cn@gmail.com>; Greg Kurz <groug@kaod.org>
>>>>> Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows 
>>>>> host
>>>>>
>>>>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>>>>>
>>>>> On Mittwoch, 13. April 2022 05:30:57 CEST Shi, Guohuai wrote:
>>>>>>> We have 3 fs drivers: local, synth, proxy. I don't mind about 
>>>>>>> proxy, it is in  bad shape and we will probably deprecate it in 
>>>>>>> near future anyway. But it would be good to have support for the 
>>>>>>> synth driver, because we are using it for running test cases and 
>>>>>>> fuzzing tests (QA).
>>>
>>> [...]
>>>
>>>> For 9p-synth:
>>>>
>>>> I had enabled 9p-synth.c and built it successfully on Windows platform.
>>>> However, test cases code are not built on Windows host.
>>>> So I think it is useless that enable synth on Windows host (no way 
>>>> to run it).
>>>
>>> Please, don't give up too soon. Looking at tests/qtest/meson.build 
>>> it starts with:
>>>
>>> # All QTests for now are POSIX-only, but the dependencies are # 
>>> really in libqtest, not in the testcases themselves.
>>> if not config_host.has_key('CONFIG_POSIX')
>>>
>>>     subdir_done()
>>>
>>> endif
>>>
>>> And looking at tests/qtest/libqtest.c I "think" this should be 
>>> working on Windows as well. It uses socket APIs which are available 
>>> on Windows. I don't see a real show stopper here for Windows.
>>>
>>> Could you please try if you can compile the tests on Windows? What 
>>> we would need is test/qtest/qos-test, we don't need all the other 
>>> tests:
>>>
>>> https://wiki.qemu.org/Documentation/9p#Test_Cases
>>>
>>>>>> It is possible that to "map" extend attribute to NTFS stream data.
>>>>>> However, if Windows host media is not NTFS (e.g. FAT) which does 
>>>>>> not support stream data, then the "map" can not work.
>>>>>
>>>>> ... yes exactly, it would make sense to use ADS [4] instead of 
>>>>> xattr on Windows. ADS are available with NTFS and ReFS and maybe 
>>>>> also with exFAT nowadays (?), not sure about the latter though. 
>>>>> But I think it is fair enough to assume Windows users to either 
>>>>> use NTFS or ReFS. And if they don't, you can still call 
>>>>> error_report_once() to make user aware that
>>>>> seucrity_model=mapped(-xattr) requires a fileystem on Windows that 
>>>>> supports ADS.
>>>>> [4] https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)
>>>>
>>>> Windows does not support POSIX permission.
>>>> So I think that only allow user to use security_model=none is 
>>>> reasonable on Windows host.
>>>
>>> It depends on the use case. I assume your use case are Windows 
>>> guests, in that case you don't have the concept of POSIX permissions 
>>> neither on guest side, nor on host side (on the long-term I am 
>>> pretty sure though that Windows guest users would want to have some 
>>> kind of Windows ACL mapping implementation as well).
>>>
>>>> There is a difficulty to support "mapped" or "mapped-file" on 
>>>> Windows
>>>> host:
>>>> There are many functions in 9p-code using APIs like "openat", 
>>>> "mkdirat", etc. MSYS does not support that (openat is not valid on 
>>>> Windows host). I remember that 9p replaced "open" by "openat" for a long time.
>>>> To fully support "security_model=mapped", 9p for Windows need to 
>>>> replace "openat" by "open". This may impact too many functions.
>>>>
>>>> I would have a try to enable "mapped" by using ADS, but it looks 
>>>> like a big refactor for 9p-local.c
>>>
>>> Regarding openat(): We had a similar challenge for macOS host 
>>> implementation; macOS does not have mknodat(), so what we're 
>>> currently doing is
>>>
>>>     pthread_fchdir_np(...)
>>>     mknod(...)
>>>
>>>     
>>> https://github.com/qemu/qemu/blob/master/hw/9pfs/9p-util-darwin.c#L8
>>> 4
>>>
>>> So on Windows you could do:
>>>     chdir(...)
>>>     open(...)
>>>
>>> as workaround for providing openat() for msys.
>>>
>>> For security_model=mapped(-xattr) to work on Windows you basically 
>>> would need to provide a replacement implementation (based on Windows 
>>> ADS) in
>>>
>>> 9p-util-windows.c for:
>>>     ssize_t fgetxattrat_nofollow(int dirfd, const char *filename, const
>>>     char
>>>
>>>                                  *name, void *value, size_t size);
>>>
>>>     ssize_t flistxattrat_nofollow(int dirfd, const char *filename,
>>>
>>>                                   char *list, size_t size);
>>>
>>>     ssize_t fremovexattrat_nofollow(int dirfd, const char *filename,
>>>
>>>                                     const char *name);
>>>
>>>     int fsetxattrat_nofollow(int dirfd, const char *filename, const char
>>>     *name,
>>>
>>>                              void *value, size_t size, int flags);
>>>
>>> So it does not look too bad I think to get security_model=mapped 
>>> working, and it would make Windows 9p host support much more usable 
>>> (for Linux guests, macOS guests, but also for Windows guests with 
>>> mapped Windows ACL in future).
>> FWIW even just having security_model=none would be very useful here, 
>> since then 9pfs could be used to share host files across all of 
>> Windows, MacOS and POSIX OSs which is something that can't yet be done with virtiofsd.
>>
>> Whilst using ADS would allow the xattrs to be attached to files, how 
>> would this work in the case of ACLs which are stored as a 
>> "system.posix_acl_access" attribute? My concern would be that files 
>> copied from the guest to the host wouldn't have sensible permissions 
>> when read directly on the host. Presumably there would be some 
>> existing precedent for how this is handled in WSL2?
>
> The behaviour with security_level=mapped on Windows would be identical 
> to that of other already supported systems, that is there are two 
> *distinct* levels for ownership and permissions in mapped mode:
>
> 1. The actual ownership information and permissions on host's file system.
> Guest won't ever get more permissions than those on host fs level, so 
> this level defines the maximum permissions if you will. Those 
> information are not directly exposed to, visible to, nor altered by guest though.
>
> 2. The ownership information and permissions mapped by 9p server. 
> That's what guest sees and is able to alter in this mode. The only 
> difference between
> security_level=mapped(-xattr) and security_level=mapped-file is just 
> the location where those mapped ownership and permissions are stored 
> to by 9p server (currently: either hidden xattr vs. hidden file).
>
> See also section "1. local fs driver" for some more explanation on this:
> https://wiki.qemu.org/Documentation/9p#9p_Filesystem_Drivers
>
> As for POSIX ACLs specifically: a Linux guest kernel does access those 
> as "system.posix_acl_access" and "system.posix_acl_default" xattrs, 
> but on host fs level they are actually stored and read by 9p server as 
> "user.virtfs.posix_acl_access" and "user.virtfs.posix_acl_default" 
> xattrs instead. So again, ACLs that may exist on host fs level are 
> separated from ACLs on guest level in mapped mode, similar to POSIX 
> ownership, permissions and device type info.

Hi Christian,

Thanks for the detailed explanation, the last paragraph above in particular clearly answers my question as to how 9pfs handles the xattr-based permissions in mapped mode.

I am certainly interested to help test later versions of the patchset.


ATB,

Mark.

Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Christian Schoenebeck]

On Dienstag, 19. April 2022 13:10:40 CEST Shi, Guohuai wrote:
> Hi All,
> 
> I just finished a basic PoC for mapped-file.
> It works! I think I can also support "security_model=map-xattr" by NTFS
> ADS.

Slick!
 
> However, I got a limitation of MinGW:
> 
> https://github.com/mirror/mingw-w64/blob/master/mingw-w64-crt/misc/dirent.c#
> L290
>  
> MinGW can not handle seekdir() while the directory has changed.
> That means, if run command like "rm -rf *", MinGW may not delete all files.
> "rm -rf *" need to call readdir()(and call seekdir() in 9P) and unlink(),
> and MinGW's seekdir() may seek directory to wrong directory entry index. 
> I am considering to change 9PFS readdir() implement on Windows host, to fix
> this problem.

To avoid history repeating [1]: please do not attempt to address this in 9p.c!
That file is the controller portion of 9p server and must remain fs-agnostic.
Such kind of issue should rather be addressed on fs driver level
(e.g. 9p-local.c, 9p-util-windows.c).

I.e. don't do it like this:
[1] https://lore.kernel.org/all/20211122004913.20052-1-wwcohen@gmail.com/T/#m734f405973768e43ce3ed7550bd21809abb25813

Best regards,
Christian Schoenebeck