[Qemu-devel] [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion()

[Qemu-devel] [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion()

[Kirill A. Shutemov]

v9fs_co_st_gen() expects to see error code in errno, not in return code.

Let's fix this.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 hw/9pfs/virtio-9p-local.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
index fc93e9e6e8da..9be8854e9148 100644
--- a/hw/9pfs/virtio-9p-local.c
+++ b/hw/9pfs/virtio-9p-local.c
@@ -1068,8 +1068,8 @@ err_out:
 static int local_ioc_getversion(FsContext *ctx, V9fsPath *path,
                                 mode_t st_mode, uint64_t *st_gen)
 {
-    int err;
 #ifdef FS_IOC_GETVERSION
+    int err;
     V9fsFidOpenState fid_open;
 
     /*
@@ -1085,10 +1085,11 @@ static int local_ioc_getversion(FsContext *ctx, V9fsPath *path,
     }
     err = ioctl(fid_open.fd, FS_IOC_GETVERSION, st_gen);
     local_close(ctx, &fid_open);
+    return err;
 #else
-    err = -ENOTTY;
+    errno = ENOTTY;
+    return -1;
 #endif
-    return err;
 }
 
 static int local_init(FsContext *ctx)
-- 
1.8.5.2

[Qemu-devel] [PATCH 2/4] hw/9pfs: handle undefined FS_IOC_GETVERSION case in handle_ioc_getversion()

[Kirill A. Shutemov]

All get_st_gen() implementations except handle_ioc_getversion() have
guard for undefined FS_IOC_GETVERSION. Let's add it there too.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 hw/9pfs/virtio-9p-handle.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
index fe8e0ed19dcc..ed8c126e1d6c 100644
--- a/hw/9pfs/virtio-9p-handle.c
+++ b/hw/9pfs/virtio-9p-handle.c
@@ -582,6 +582,7 @@ static int handle_unlinkat(FsContext *ctx, V9fsPath *dir,
 static int handle_ioc_getversion(FsContext *ctx, V9fsPath *path,
                                  mode_t st_mode, uint64_t *st_gen)
 {
+#ifdef FS_IOC_GETVERSION
     int err;
     V9fsFidOpenState fid_open;
 
@@ -599,6 +600,10 @@ static int handle_ioc_getversion(FsContext *ctx, V9fsPath *path,
     err = ioctl(fid_open.fd, FS_IOC_GETVERSION, st_gen);
     handle_close(ctx, &fid_open);
     return err;
+#else
+    errno = ENOTTY;
+    return -1;
+#endif
 }
 
 static int handle_init(FsContext *ctx)
-- 
1.8.5.2

[Qemu-devel] [PATCH 3/4] hw/9pfs: make get_st_gen() return ENOTTY error on special files

[Kirill A. Shutemov]

Currently we silently ignore getversion requests for anything except
file or directory. Let's instead return ENOTTY error to indicate that
getversion is not supported. It makes implementation consistent on
all not-supported cases.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 hw/9pfs/virtio-9p-handle.c | 3 ++-
 hw/9pfs/virtio-9p-local.c  | 3 ++-
 hw/9pfs/virtio-9p-proxy.c  | 3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
index ed8c126e1d6c..17002a3d2867 100644
--- a/hw/9pfs/virtio-9p-handle.c
+++ b/hw/9pfs/virtio-9p-handle.c
@@ -591,7 +591,8 @@ static int handle_ioc_getversion(FsContext *ctx, V9fsPath *path,
      * We can get fd for regular files and directories only
      */
     if (!S_ISREG(st_mode) && !S_ISDIR(st_mode)) {
-            return 0;
+        errno = ENOTTY;
+        return -1;
     }
     err = handle_open(ctx, path, O_RDONLY, &fid_open);
     if (err < 0) {
diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
index 9be8854e9148..df0dbffa7ac4 100644
--- a/hw/9pfs/virtio-9p-local.c
+++ b/hw/9pfs/virtio-9p-local.c
@@ -1077,7 +1077,8 @@ static int local_ioc_getversion(FsContext *ctx, V9fsPath *path,
      * We can get fd for regular files and directories only
      */
     if (!S_ISREG(st_mode) && !S_ISDIR(st_mode)) {
-            return 0;
+        errno = ENOTTY;
+        return -1;
     }
     err = local_open(ctx, path, O_RDONLY, &fid_open);
     if (err < 0) {
diff --git a/hw/9pfs/virtio-9p-proxy.c b/hw/9pfs/virtio-9p-proxy.c
index 5f44bb758b35..b57966d9d883 100644
--- a/hw/9pfs/virtio-9p-proxy.c
+++ b/hw/9pfs/virtio-9p-proxy.c
@@ -1086,7 +1086,8 @@ static int proxy_ioc_getversion(FsContext *fs_ctx, V9fsPath *path,
      * we can get fd for regular files and directories only
      */
     if (!S_ISREG(st_mode) && !S_ISDIR(st_mode)) {
-        return 0;
+        errno = ENOTTY;
+        return -1;
     }
     err = v9fs_request(fs_ctx->private, T_GETVERSION, st_gen, "s", path);
     if (err < 0) {
-- 
1.8.5.2

[Qemu-devel] [PATCH 4/4] hw/9pfs: fix P9_STATS_GEN handling

[Kirill A. Shutemov]

Currently we fail getattr request altogether if we can't read
P9_STATS_GEN for some reason. It breaks valid use cases:

E.g let's assume we have non-readable directory with execution bit set
on host and we export it to client over 9p On host we can chdir into
directory, but not open directory on read and list content.

But if client will try to call getattr (as part of chdir(2)) for the
directory it will fail with -EACCES. It happens because we try to open
the directory on read to call ioctl(FS_IOC_GETVERSION), it fails and we
return the error code to client.

It's excessive. The solution is to make P9_STATS_GEN failure non-fatal
for getattr request. Just don't set P9_STATS_GEN flag in result mask on
failure.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 hw/9pfs/cofile.c    |  4 ----
 hw/9pfs/virtio-9p.c | 12 ++++++++++--
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/hw/9pfs/cofile.c b/hw/9pfs/cofile.c
index 194c1306c665..2efebf35710f 100644
--- a/hw/9pfs/cofile.c
+++ b/hw/9pfs/cofile.c
@@ -38,10 +38,6 @@ int v9fs_co_st_gen(V9fsPDU *pdu, V9fsPath *path, mode_t st_mode,
             });
         v9fs_path_unlock(s);
     }
-    /* The ioctl may not be supported depending on the path */
-    if (err == -ENOTTY) {
-        err = 0;
-    }
     return err;
 }
 
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 8cbb8ae32a03..83e4e9398347 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1080,10 +1080,18 @@ static void v9fs_getattr(void *opaque)
     /*  fill st_gen if requested and supported by underlying fs */
     if (request_mask & P9_STATS_GEN) {
         retval = v9fs_co_st_gen(pdu, &fidp->path, stbuf.st_mode, &v9stat_dotl);
-        if (retval < 0) {
+        switch (retval) {
+        case 0:
+            /* we have valid st_gen: update result mask */
+            v9stat_dotl.st_result_mask |= P9_STATS_GEN;
+            break;
+        case -EINTR:
+            /* request cancelled, e.g. by Tflush */
             goto out;
+        default:
+            /* failed to get st_gen: not fatal, ignore */
+            break;
         }
-        v9stat_dotl.st_result_mask |= P9_STATS_GEN;
     }
     retval = pdu_marshal(pdu, offset, "A", &v9stat_dotl);
     if (retval < 0) {
-- 
1.8.5.2

Re: [Qemu-devel] [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion()

[Aneesh Kumar K.V]

"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:

> v9fs_co_st_gen() expects to see error code in errno, not in return code.
>
> Let's fix this.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

> ---
>  hw/9pfs/virtio-9p-local.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
> index fc93e9e6e8da..9be8854e9148 100644
> --- a/hw/9pfs/virtio-9p-local.c
> +++ b/hw/9pfs/virtio-9p-local.c
> @@ -1068,8 +1068,8 @@ err_out:
>  static int local_ioc_getversion(FsContext *ctx, V9fsPath *path,
>                                  mode_t st_mode, uint64_t *st_gen)
>  {
> -    int err;
>  #ifdef FS_IOC_GETVERSION
> +    int err;
>      V9fsFidOpenState fid_open;
>
>      /*
> @@ -1085,10 +1085,11 @@ static int local_ioc_getversion(FsContext *ctx, V9fsPath *path,
>      }
>      err = ioctl(fid_open.fd, FS_IOC_GETVERSION, st_gen);
>      local_close(ctx, &fid_open);
> +    return err;
>  #else
> -    err = -ENOTTY;
> +    errno = ENOTTY;
> +    return -1;
>  #endif
> -    return err;
>  }
>
>  static int local_init(FsContext *ctx)
> -- 
> 1.8.5.2

Re: [Qemu-devel] [PATCH 2/4] hw/9pfs: handle undefined FS_IOC_GETVERSION case in handle_ioc_getversion()

[Aneesh Kumar K.V]

"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:

> All get_st_gen() implementations except handle_ioc_getversion() have
> guard for undefined FS_IOC_GETVERSION. Let's add it there too.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

> ---
>  hw/9pfs/virtio-9p-handle.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
> index fe8e0ed19dcc..ed8c126e1d6c 100644
> --- a/hw/9pfs/virtio-9p-handle.c
> +++ b/hw/9pfs/virtio-9p-handle.c
> @@ -582,6 +582,7 @@ static int handle_unlinkat(FsContext *ctx, V9fsPath *dir,
>  static int handle_ioc_getversion(FsContext *ctx, V9fsPath *path,
>                                   mode_t st_mode, uint64_t *st_gen)
>  {
> +#ifdef FS_IOC_GETVERSION
>      int err;
>      V9fsFidOpenState fid_open;
>
> @@ -599,6 +600,10 @@ static int handle_ioc_getversion(FsContext *ctx, V9fsPath *path,
>      err = ioctl(fid_open.fd, FS_IOC_GETVERSION, st_gen);
>      handle_close(ctx, &fid_open);
>      return err;
> +#else
> +    errno = ENOTTY;
> +    return -1;
> +#endif
>  }
>
>  static int handle_init(FsContext *ctx)
> -- 
> 1.8.5.2

Re: [Qemu-devel] [PATCH 4/4] hw/9pfs: fix P9_STATS_GEN handling

[Aneesh Kumar K.V]

"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:

> Currently we fail getattr request altogether if we can't read
> P9_STATS_GEN for some reason. It breaks valid use cases:
>
> E.g let's assume we have non-readable directory with execution bit set
> on host and we export it to client over 9p On host we can chdir into
> directory, but not open directory on read and list content.
>
> But if client will try to call getattr (as part of chdir(2)) for the
> directory it will fail with -EACCES. It happens because we try to open
> the directory on read to call ioctl(FS_IOC_GETVERSION), it fails and we
> return the error code to client.
>
> It's excessive. The solution is to make P9_STATS_GEN failure non-fatal
> for getattr request. Just don't set P9_STATS_GEN flag in result mask on
> failure.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>


Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

> ---
>  hw/9pfs/cofile.c    |  4 ----
>  hw/9pfs/virtio-9p.c | 12 ++++++++++--
>  2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/hw/9pfs/cofile.c b/hw/9pfs/cofile.c
> index 194c1306c665..2efebf35710f 100644
> --- a/hw/9pfs/cofile.c
> +++ b/hw/9pfs/cofile.c
> @@ -38,10 +38,6 @@ int v9fs_co_st_gen(V9fsPDU *pdu, V9fsPath *path, mode_t st_mode,
>              });
>          v9fs_path_unlock(s);
>      }
> -    /* The ioctl may not be supported depending on the path */
> -    if (err == -ENOTTY) {
> -        err = 0;
> -    }
>      return err;
>  }
>
> diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> index 8cbb8ae32a03..83e4e9398347 100644
> --- a/hw/9pfs/virtio-9p.c
> +++ b/hw/9pfs/virtio-9p.c
> @@ -1080,10 +1080,18 @@ static void v9fs_getattr(void *opaque)
>      /*  fill st_gen if requested and supported by underlying fs */
>      if (request_mask & P9_STATS_GEN) {
>          retval = v9fs_co_st_gen(pdu, &fidp->path, stbuf.st_mode, &v9stat_dotl);
> -        if (retval < 0) {
> +        switch (retval) {
> +        case 0:
> +            /* we have valid st_gen: update result mask */
> +            v9stat_dotl.st_result_mask |= P9_STATS_GEN;
> +            break;
> +        case -EINTR:
> +            /* request cancelled, e.g. by Tflush */
>              goto out;
> +        default:
> +            /* failed to get st_gen: not fatal, ignore */
> +            break;
>          }
> -        v9stat_dotl.st_result_mask |= P9_STATS_GEN;
>      }
>      retval = pdu_marshal(pdu, offset, "A", &v9stat_dotl);
>      if (retval < 0) {
> -- 
> 1.8.5.2

Re: [Qemu-devel] [PATCH 3/4] hw/9pfs: make get_st_gen() return ENOTTY error on special files

[Aneesh Kumar K.V]

"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:

> Currently we silently ignore getversion requests for anything except
> file or directory. Let's instead return ENOTTY error to indicate that
> getversion is not supported. It makes implementation consistent on
> all not-supported cases.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

> ---
>  hw/9pfs/virtio-9p-handle.c | 3 ++-
>  hw/9pfs/virtio-9p-local.c  | 3 ++-
>  hw/9pfs/virtio-9p-proxy.c  | 3 ++-
>  3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
> index ed8c126e1d6c..17002a3d2867 100644
> --- a/hw/9pfs/virtio-9p-handle.c
> +++ b/hw/9pfs/virtio-9p-handle.c
> @@ -591,7 +591,8 @@ static int handle_ioc_getversion(FsContext *ctx, V9fsPath *path,
>       * We can get fd for regular files and directories only
>       */
>      if (!S_ISREG(st_mode) && !S_ISDIR(st_mode)) {
> -            return 0;
> +        errno = ENOTTY;
> +        return -1;
>      }
>      err = handle_open(ctx, path, O_RDONLY, &fid_open);
>      if (err < 0) {
> diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
> index 9be8854e9148..df0dbffa7ac4 100644
> --- a/hw/9pfs/virtio-9p-local.c
> +++ b/hw/9pfs/virtio-9p-local.c
> @@ -1077,7 +1077,8 @@ static int local_ioc_getversion(FsContext *ctx, V9fsPath *path,
>       * We can get fd for regular files and directories only
>       */
>      if (!S_ISREG(st_mode) && !S_ISDIR(st_mode)) {
> -            return 0;
> +        errno = ENOTTY;
> +        return -1;
>      }
>      err = local_open(ctx, path, O_RDONLY, &fid_open);
>      if (err < 0) {
> diff --git a/hw/9pfs/virtio-9p-proxy.c b/hw/9pfs/virtio-9p-proxy.c
> index 5f44bb758b35..b57966d9d883 100644
> --- a/hw/9pfs/virtio-9p-proxy.c
> +++ b/hw/9pfs/virtio-9p-proxy.c
> @@ -1086,7 +1086,8 @@ static int proxy_ioc_getversion(FsContext *fs_ctx, V9fsPath *path,
>       * we can get fd for regular files and directories only
>       */
>      if (!S_ISREG(st_mode) && !S_ISDIR(st_mode)) {
> -        return 0;
> +        errno = ENOTTY;
> +        return -1;
>      }
>      err = v9fs_request(fs_ctx->private, T_GETVERSION, st_gen, "s", path);
>      if (err < 0) {
> -- 
> 1.8.5.2

[Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Michael S. Tsirkin]

Haven't used 9pfs in a while.
I thought these patches are a good time to play with it some more.
I have encountered two issues.

What I'm doing:
host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.

/scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu kvm64
-smp 2  f20-x64.qcow2  -netdev user,id=foo -redir tcp:8022::22 -device
virtio-net,netdev=foo  -serial stdio -fsdev
local,security_model=none,id=fsdev0,path=/lib/modules/ -device
virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
local,security_model=none,id=fsdev1,path=/boot -device
virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
-snapshot

guest: Fedora 20

added this in /etc/fstab:

bootshare       /share/boot     9p      trans=virtio,version=9p2000.L 0 0
libmodulesshare /share/lib/modules      9p trans=virtio,version=9p2000.L 0 0


I have encountered two issues:

1. mount failure on boot
If I try to mount on boot through fstab, I get:
[    2.270157] 9pnet: Could not find request transport: virtio
[    2.270158] 9pnet: Could not find request transport: virtio

If I then re-try mount, it succeeds immediately!

Some kind of dependency issue?

2. files immediately in the mounted directory aren't visible on the
guest under /share/boot.
For example, files under /boot on host are not visible
on guest, files under child directories seem visible.

Strange.

-- 
MST

Re: [Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Aneesh Kumar K.V]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> Haven't used 9pfs in a while.
> I thought these patches are a good time to play with it some more.
> I have encountered two issues.
>
> What I'm doing:
> host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.
>
> /scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu kvm64
> -smp 2  f20-x64.qcow2  -netdev user,id=foo -redir tcp:8022::22 -device
> virtio-net,netdev=foo  -serial stdio -fsdev
> local,security_model=none,id=fsdev0,path=/lib/modules/ -device
> virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
> local,security_model=none,id=fsdev1,path=/boot -device
> virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
> -snapshot
>
> guest: Fedora 20
>
> added this in /etc/fstab:
>
> bootshare       /share/boot     9p      trans=virtio,version=9p2000.L 0 0
> libmodulesshare /share/lib/modules      9p trans=virtio,version=9p2000.L 0 0
>
>
> I have encountered two issues:
>
> 1. mount failure on boot
> If I try to mount on boot through fstab, I get:
> [    2.270157] 9pnet: Could not find request transport: virtio
> [    2.270158] 9pnet: Could not find request transport: virtio


Missing 9pnet_virtio.ko module ? 

>
> If I then re-try mount, it succeeds immediately!
>
> Some kind of dependency issue?
>
> 2. files immediately in the mounted directory aren't visible on the
> guest under /share/boot.
> For example, files under /boot on host are not visible
> on guest, files under child directories seem visible.


can you share more details on this ? /boot permissions. ls -al output on
host etc.

-aneesh

Re: [Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Michael S. Tsirkin]

On Mon, Feb 03, 2014 at 03:05:10PM +0530, Aneesh Kumar K.V wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > Haven't used 9pfs in a while.
> > I thought these patches are a good time to play with it some more.
> > I have encountered two issues.
> >
> > What I'm doing:
> > host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.
> >
> > /scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu kvm64
> > -smp 2  f20-x64.qcow2  -netdev user,id=foo -redir tcp:8022::22 -device
> > virtio-net,netdev=foo  -serial stdio -fsdev
> > local,security_model=none,id=fsdev0,path=/lib/modules/ -device
> > virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
> > local,security_model=none,id=fsdev1,path=/boot -device
> > virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
> > -snapshot
> >
> > guest: Fedora 20
> >
> > added this in /etc/fstab:
> >
> > bootshare       /share/boot     9p      trans=virtio,version=9p2000.L 0 0
> > libmodulesshare /share/lib/modules      9p trans=virtio,version=9p2000.L 0 0
> >
> >
> > I have encountered two issues:
> >
> > 1. mount failure on boot
> > If I try to mount on boot through fstab, I get:
> > [    2.270157] 9pnet: Could not find request transport: virtio
> > [    2.270158] 9pnet: Could not find request transport: virtio
> 
> 
> Missing 9pnet_virtio.ko module ? 

Maybe it's loaded too late. But when I get to plymouth prompt
it's loaded fine.

> >
> > If I then re-try mount, it succeeds immediately!
> >
> > Some kind of dependency issue?
> >
> > 2. files immediately in the mounted directory aren't visible on the
> > guest under /share/boot.
> > For example, files under /boot on host are not visible
> > on guest, files under child directories seem visible.
> 
> 
> can you share more details on this ? /boot permissions. ls -al output on
> host etc.
> 
> -aneesh

for /boot:
dr-xr-xr-x. 7 root root 12288 Feb  2 23:41 /boot/

$ ls -la
total 739740
dr-xr-xr-x.  7 root root    12288 Feb  2 23:41 .
dr-xr-xr-x. 22 root root     4096 Feb  2 19:16 ..
-rw-r--r--.  1 root root   138741 Dec 23 19:19 config-3.12.6-200.fc19.i686
-rw-r--r--.  1 root root   138724 Jan 10 18:06 config-3.12.7-200.fc19.i686
-rw-r--r--.  1 root root   138724 Jan 16 06:43 config-3.12.8-200.fc19.i686
drwxr-xr-x.  3 root root     4096 May 22  2012 efi
-rw-r--r--.  1 root root   178176 Sep 16 13:14 elf-memtest86+-4.20
drwxr-xr-x.  2 root root     4096 Sep  8 14:40 extlinux
drwxr-xr-x.  2 root root     4096 Jan 24  2013 grub
drwxr-xr-x.  6 root root     4096 Feb  2 23:41 grub2
-rw-------.  1 root root 25541989 Sep  8 16:12 initramfs-0-rescue-2b6e810f801e4f458fa97f9a3b9c8a3e.img
-rw-------.  1 root root  7633329 Jul 11  2013 initramfs-3.10.0-mst.img
-rw-------.  1 root root  7745838 May 30  2013 initramfs-3.10.0-rc3-mst.img
-rw-------.  1 root root  7629376 Jul  4  2013 initramfs-3.10.0-rc6-mst.img
-rw-------.  1 root root  7481618 Sep 22 17:21 initramfs-3.11.0-mst.img
-rw-------.  1 root root  7657392 Aug  7 16:39 initramfs-3.11.0-rc3-mst.img
-rw-------.  1 root root  7659204 Aug 18 13:21 initramfs-3.11.0-rc5-mst.img
-rw-------.  1 root root  7658165 Aug 26 11:47 initramfs-3.11.0-rc7-mst.img
-rw-------.  1 root root  7510290 Nov 20 15:38 initramfs-3.12.0-mst.img
-rw-------.  1 root root  7277585 Sep 29 15:14 initramfs-3.12.0-rc2-mst.img
-rw-------.  1 root root  7277729 Oct 31 07:48 initramfs-3.12.0-rc5-mst.img
-rw-------.  1 root root  8118663 Jan  6 12:31 initramfs-3.12.6-200.fc19.i686.img
-rw-------.  1 root root  7273738 Jan 18 19:14 initramfs-3.12.7-200.fc19.i686.img
-rw-------.  1 root root  7272946 Jan 26 16:54 initramfs-3.12.8-200.fc19.i686.img
-rw-r--r--.  1 root root  7334316 Feb  2 23:41 initramfs-3.13.0-mst.img
-rw-r--r--.  1 root root 13623844 Jul 19  2012 initramfs-3.4.0-test.img
-rw-r--r--.  1 root root 14134095 Jun 17  2012 initramfs-3.5.0-rc2.img
-rw-r--r--.  1 root root  6195273 Jun 18  2012 initramfs-3.5.0-rc2-mst.img
-rw-r--r--.  1 root root 14137528 Jun 25  2012 initramfs-3.5.0-rc4-mst.img
-rw-r--r--.  1 root root 14145675 Jul 19  2012 initramfs-3.5.0-rc7-mst.img
-rw-r--r--.  1 root root 14219388 Aug 14  2012 initramfs-3.6.0-rc1-mst.img
-rw-r--r--.  1 root root 14230447 Sep  5  2012 initramfs-3.6.0-rc3-mst.img
-rw-r--r--.  1 root root 14229895 Sep 25  2012 initramfs-3.6.0-rc5-mst.img
-rw-------.  1 root root 14431655 Nov  1  2012 initramfs-3.7.0-rc1-mst.img
-rw-------.  1 root root 14432680 Oct 29  2012 initramfs-3.7.0-rc2-mst.img
-rw-------.  1 root root 14436612 Dec  5  2012 initramfs-3.7.0-rc7-mst.img
-rw-------.  1 root root  7485502 Feb 28  2013 initramfs-3.8.0-mst.img
-rw-------.  1 root root 14549268 Jan  7  2013 initramfs-3.8.0-rc2-mst.img
-rw-------.  1 root root 14544287 Jan 16  2013 initramfs-3.8.0-rc3-mst.img
-rw-------.  1 root root  7549459 Jan 24  2013 initramfs-3.8.0-rc4-mst.img
-rw-------.  1 root root  7434071 Feb  7  2013 initramfs-3.8.0-rc5-mst.img
-rw-------.  1 root root  7433015 Feb  5  2013 initramfs-3.8.0-rc6-mst.img
-rw-------.  1 root root  7533783 Apr  4  2013 initramfs-3.9.0-rc5-mst.img
-rw-------.  1 root root  7551614 May  7  2013 initramfs-3.9.0-rc8-mst.img
-rw-------.  1 root root  7276896 Sep 29 15:13 initrd-3.12.0-rc2-mst.img
-rw-r--r--.  1 root root   331065 Nov 14 12:58 initrd-plymouth.img
drwx------.  2 root root    16384 Jun 14  2012 lost+found
-rw-r--r--.  1 root root   176500 Sep 16 13:14 memtest86+-4.20
lrwxrwxrwx.  1 root root       27 Feb  2 23:40 System.map -> /boot/System.map-3.13.0-mst
-rw-r--r--.  1 root root  2528545 Jul 11  2013 System.map-3.10.0-mst
-rw-r--r--.  1 root root  2528828 Jul  9  2013 System.map-3.10.0-mst.old
-rw-r--r--.  1 root root  2487719 May 30  2013 System.map-3.10.0-rc3-mst
-rw-r--r--.  1 root root  2527425 Jul  4  2013 System.map-3.10.0-rc6-mst
-rw-r--r--.  1 root root  2527425 Jul  4  2013 System.map-3.10.0-rc6-mst.old
-rw-r--r--.  1 root root  2529718 Sep 22 17:21 System.map-3.11.0-mst
-rw-r--r--.  1 root root  2529718 Sep 22 17:02 System.map-3.11.0-mst.old
-rw-r--r--.  1 root root  2576397 Aug  7 16:39 System.map-3.11.0-rc3-mst
-rw-r--r--.  1 root root  2576397 Aug  1  2013 System.map-3.11.0-rc3-mst.old
-rw-r--r--.  1 root root  2576487 Aug 18 13:20 System.map-3.11.0-rc5-mst
-rw-r--r--.  1 root root  2576731 Aug 26 11:47 System.map-3.11.0-rc7-mst
-rw-r--r--.  1 root root  2588033 Nov 20 15:37 System.map-3.12.0-mst
-rw-r--r--.  1 root root  2572249 Nov 20 12:42 System.map-3.12.0-mst.old
-rw-r--r--.  1 root root  2570623 Sep 29 15:14 System.map-3.12.0-rc2-mst
-rw-r--r--.  1 root root  2570623 Sep 29 14:55 System.map-3.12.0-rc2-mst.old
-rw-r--r--.  1 root root  2571961 Oct 31 07:47 System.map-3.12.0-rc5-mst
-rw-r--r--.  1 root root  2571961 Oct 31 07:45 System.map-3.12.0-rc5-mst.old
-rw-------.  1 root root  2141860 Dec 23 19:19 System.map-3.12.6-200.fc19.i686
-rw-------.  1 root root  2141831 Jan 10 18:06 System.map-3.12.7-200.fc19.i686
-rw-------.  1 root root  2141926 Jan 16 06:43 System.map-3.12.8-200.fc19.i686
-rw-r--r--.  1 root root  2620357 Feb  2 23:40 System.map-3.13.0-mst
-rw-r--r--.  1 root root  2620357 Feb  2 22:49 System.map-3.13.0-mst.old
-rw-r--r--.  1 root root  2376364 Jul 19  2012 System.map-3.4.0-test
-rw-r--r--.  1 root root  2401058 Jun 17  2012 System.map-3.5.0-rc2
-rw-r--r--.  1 root root  2923379 Jun 18  2012 System.map-3.5.0-rc2-mst
-rw-r--r--.  1 root root  3063236 Jun 17  2012 System.map-3.5.0-rc2-mst.old
-rw-r--r--.  1 root root  2401935 Jun 25  2012 System.map-3.5.0-rc4-mst
-rw-r--r--.  1 root root  2402178 Jul 19  2012 System.map-3.5.0-rc7-mst
-rw-r--r--.  1 root root  2402090 Jul 15  2012 System.map-3.5.0-rc7-mst.old
-rw-r--r--.  1 root root  2431223 Aug 14  2012 System.map-3.6.0-rc1-mst
-rw-r--r--.  1 root root  2433233 Aug  5  2012 System.map-3.6.0-rc1-mst.old
-rw-r--r--.  1 root root  2432386 Sep  5  2012 System.map-3.6.0-rc3-mst
-rw-r--r--.  1 root root  2432386 Sep  5  2012 System.map-3.6.0-rc3-mst.old
-rw-r--r--.  1 root root  2432980 Sep 25  2012 System.map-3.6.0-rc5-mst
-rw-r--r--.  1 root root  2458509 Nov  1  2012 System.map-3.7.0-rc1-mst
-rw-r--r--.  1 root root  2458509 Oct 31  2012 System.map-3.7.0-rc1-mst.old
-rw-r--r--.  1 root root  2458009 Oct 29  2012 System.map-3.7.0-rc2-mst
-rw-r--r--.  1 root root  2458009 Oct 29  2012 System.map-3.7.0-rc2-mst.old
-rw-r--r--.  1 root root  2461557 Dec  5  2012 System.map-3.7.0-rc7-mst
-rw-r--r--.  1 root root  2496523 Feb 28  2013 System.map-3.8.0-mst
-rw-r--r--.  1 root root  2496523 Feb 28  2013 System.map-3.8.0-mst.old
-rw-r--r--.  1 root root  2493704 Jan  7  2013 System.map-3.8.0-rc2-mst
-rw-r--r--.  1 root root  2494171 Jan 16  2013 System.map-3.8.0-rc3-mst
-rw-r--r--.  1 root root  2494458 Jan 24  2013 System.map-3.8.0-rc4-mst
-rw-r--r--.  1 root root  2494458 Jan 24  2013 System.map-3.8.0-rc4-mst.old
-rw-r--r--.  1 root root  2495697 Feb  7  2013 System.map-3.8.0-rc5-mst
-rw-r--r--.  1 root root  2496119 Feb  5  2013 System.map-3.8.0-rc6-mst
-rw-r--r--.  1 root root  2496119 Feb  5  2013 System.map-3.8.0-rc6-mst.old
-rw-r--r--.  1 root root  2535010 Apr  4  2013 System.map-3.9.0-rc5-mst
-rw-r--r--.  1 root root  2535010 Apr  4  2013 System.map-3.9.0-rc5-mst.old
-rw-r--r--.  1 root root  2537825 May  7  2013 System.map-3.9.0-rc8-mst
-rw-r--r--.  1 root root  2537965 May  2  2013 System.map-3.9.0-rc8-mst.old
lrwxrwxrwx.  1 root root       24 Feb  2 23:40 vmlinuz -> /boot/vmlinuz-3.13.0-mst
-rwxr-xr-x.  1 root root  4979280 Sep  8 16:12 vmlinuz-0-rescue-2b6e810f801e4f458fa97f9a3b9c8a3e
-rw-r--r--.  1 root root  5027584 Jul 11  2013 vmlinuz-3.10.0-mst
-rw-r--r--.  1 root root  5027520 Jul  9  2013 vmlinuz-3.10.0-mst.old
-rw-r--r--.  1 root root  4906912 May 30  2013 vmlinuz-3.10.0-rc3-mst
-rw-r--r--.  1 root root  5018368 Jul  4  2013 vmlinuz-3.10.0-rc6-mst
-rw-r--r--.  1 root root  5018368 Jul  4  2013 vmlinuz-3.10.0-rc6-mst.old
-rw-r--r--.  1 root root  4950784 Sep 22 17:21 vmlinuz-3.11.0-mst
-rw-r--r--.  1 root root  4950784 Sep 22 17:02 vmlinuz-3.11.0-mst.old
-rw-r--r--.  1 root root  5071552 Aug  7 16:39 vmlinuz-3.11.0-rc3-mst
-rw-r--r--.  1 root root  5071552 Aug  1  2013 vmlinuz-3.11.0-rc3-mst.old
-rw-r--r--.  1 root root  5071968 Aug 18 13:20 vmlinuz-3.11.0-rc5-mst
-rw-r--r--.  1 root root  5073440 Aug 26 11:47 vmlinuz-3.11.0-rc7-mst
-rw-r--r--.  1 root root  5050992 Nov 20 15:37 vmlinuz-3.12.0-mst
-rw-r--r--.  1 root root  5033216 Nov 20 12:42 vmlinuz-3.12.0-mst.old
-rw-r--r--.  1 root root  5030304 Sep 29 15:14 vmlinuz-3.12.0-rc2-mst
-rw-r--r--.  1 root root  5030304 Sep 29 14:55 vmlinuz-3.12.0-rc2-mst.old
-rw-r--r--.  1 root root  5032064 Oct 31 07:47 vmlinuz-3.12.0-rc5-mst
-rw-r--r--.  1 root root  5032064 Oct 31 07:45 vmlinuz-3.12.0-rc5-mst.old
-rwxr-xr-x.  1 root root  5129456 Dec 23 19:19 vmlinuz-3.12.6-200.fc19.i686
-rw-r--r--.  1 root root      165 Dec 23 19:19 .vmlinuz-3.12.6-200.fc19.i686.hmac
-rwxr-xr-x.  1 root root  5129712 Jan 10 18:06 vmlinuz-3.12.7-200.fc19.i686
-rw-r--r--.  1 root root      165 Jan 10 18:06 .vmlinuz-3.12.7-200.fc19.i686.hmac
-rwxr-xr-x.  1 root root  5129520 Jan 16 06:43 vmlinuz-3.12.8-200.fc19.i686
-rw-r--r--.  1 root root      165 Jan 16 06:43 .vmlinuz-3.12.8-200.fc19.i686.hmac
-rw-r--r--.  1 root root  5125840 Feb  2 23:40 vmlinuz-3.13.0-mst
-rw-r--r--.  1 root root  5125840 Feb  2 22:49 vmlinuz-3.13.0-mst.old
-rw-r--r--.  1 root root  4698032 Jul 19  2012 vmlinuz-3.4.0-test
-rw-r--r--.  1 root root  4753376 Jun 17  2012 vmlinuz-3.5.0-rc2
-rw-r--r--.  1 root root  5968288 Jun 18  2012 vmlinuz-3.5.0-rc2-mst
-rw-r--r--.  1 root root  5541856 Jun 17  2012 vmlinuz-3.5.0-rc2-mst.old
-rw-r--r--.  1 root root  4756800 Jun 25  2012 vmlinuz-3.5.0-rc4-mst
-rw-r--r--.  1 root root  4757888 Jul 19  2012 vmlinuz-3.5.0-rc7-mst
-rw-r--r--.  1 root root  4756640 Jul 15  2012 vmlinuz-3.5.0-rc7-mst.old
-rw-r--r--.  1 root root  4783232 Aug 14  2012 vmlinuz-3.6.0-rc1-mst
-rw-r--r--.  1 root root  4784736 Aug  5  2012 vmlinuz-3.6.0-rc1-mst.old
-rw-r--r--.  1 root root  4788768 Sep  5  2012 vmlinuz-3.6.0-rc3-mst
-rw-r--r--.  1 root root  4788768 Sep  5  2012 vmlinuz-3.6.0-rc3-mst.old
-rw-r--r--.  1 root root  4789824 Sep 25  2012 vmlinuz-3.6.0-rc5-mst
-rw-r--r--.  1 root root  4855680 Nov  1  2012 vmlinuz-3.7.0-rc1-mst
-rw-r--r--.  1 root root  4855456 Oct 31  2012 vmlinuz-3.7.0-rc1-mst.old
-rw-r--r--.  1 root root  4854176 Oct 29  2012 vmlinuz-3.7.0-rc2-mst
-rw-r--r--.  1 root root  4854176 Oct 29  2012 vmlinuz-3.7.0-rc2-mst.old
-rw-r--r--.  1 root root  4861632 Dec  5  2012 vmlinuz-3.7.0-rc7-mst
-rw-r--r--.  1 root root  4930768 Feb 28  2013 vmlinuz-3.8.0-mst
-rw-r--r--.  1 root root  4930768 Feb 28  2013 vmlinuz-3.8.0-mst.old
-rw-r--r--.  1 root root  4926128 Jan  7  2013 vmlinuz-3.8.0-rc2-mst
-rw-r--r--.  1 root root  4927184 Jan 16  2013 vmlinuz-3.8.0-rc3-mst
-rw-r--r--.  1 root root  4927280 Jan 24  2013 vmlinuz-3.8.0-rc4-mst
-rw-r--r--.  1 root root  4927280 Jan 24  2013 vmlinuz-3.8.0-rc4-mst.old
-rw-r--r--.  1 root root  4930832 Feb  7  2013 vmlinuz-3.8.0-rc5-mst
-rw-r--r--.  1 root root  4929616 Feb  5  2013 vmlinuz-3.8.0-rc6-mst
-rw-r--r--.  1 root root  4929616 Feb  5  2013 vmlinuz-3.8.0-rc6-mst.old
-rw-r--r--.  1 root root  4997664 Apr  4  2013 vmlinuz-3.9.0-rc5-mst
-rw-r--r--.  1 root root  4997664 Apr  4  2013 vmlinuz-3.9.0-rc5-mst.old
-rw-r--r--.  1 root root  5014112 May  7  2013 vmlinuz-3.9.0-rc8-mst
-rw-r--r--.  1 root root  5014752 May  2  2013 vmlinuz-3.9.0-rc8-mst.old

Re: [Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Aneesh Kumar K.V]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Mon, Feb 03, 2014 at 03:05:10PM +0530, Aneesh Kumar K.V wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> 
>> > Haven't used 9pfs in a while.
>> > I thought these patches are a good time to play with it some more.
>> > I have encountered two issues.
>> >
>> > What I'm doing:
>> > host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.
>> >
>> > /scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu kvm64
>> > -smp 2  f20-x64.qcow2  -netdev user,id=foo -redir tcp:8022::22 -device
>> > virtio-net,netdev=foo  -serial stdio -fsdev
>> > local,security_model=none,id=fsdev0,path=/lib/modules/ -device
>> > virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
>> > local,security_model=none,id=fsdev1,path=/boot -device
>> > virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
>> > -snapshot
>> >
>> > guest: Fedora 20
>> >
>> > added this in /etc/fstab:
>> >
>> > bootshare       /share/boot     9p      trans=virtio,version=9p2000.L 0 0
>> > libmodulesshare /share/lib/modules      9p trans=virtio,version=9p2000.L 0 0
>> >
>> >
>> > I have encountered two issues:
>> >
>> > 1. mount failure on boot
>> > If I try to mount on boot through fstab, I get:
>> > [    2.270157] 9pnet: Could not find request transport: virtio
>> > [    2.270158] 9pnet: Could not find request transport: virtio
>> 
>> 
>> Missing 9pnet_virtio.ko module ? 
>
> Maybe it's loaded too late. But when I get to plymouth prompt
> it's loaded fine.
>
>> >
>> > If I then re-try mount, it succeeds immediately!
>> >
>> > Some kind of dependency issue?
>> >
>> > 2. files immediately in the mounted directory aren't visible on the
>> > guest under /share/boot.
>> > For example, files under /boot on host are not visible
>> > on guest, files under child directories seem visible.
>> 
>> 
>> can you share more details on this ? /boot permissions. ls -al output on
>> host etc.
>> 
>> -aneesh
>
> for /boot:
> dr-xr-xr-x. 7 root root 12288 Feb  2 23:41 /boot/
>
> $ ls -la
> total 739740
> dr-xr-xr-x.  7 root root    12288 Feb  2 23:41 .
> dr-xr-xr-x. 22 root root     4096 Feb  2 19:16 ..
> -rw-r--r--.  1 root root   138741 Dec 23 19:19 config-3.12.6-200.fc19.i686
> -rw-r--r--.  1 root root   138724 Jan 10 18:06 config-3.12.7-200.fc19.i686
> -rw-r--r--.  1 root root   138724 Jan 16 06:43
> config-3.12.8-200.fc19.i686


Related to SELinux errors ? can you double check you don't selinux
errors.

Can you also share the file listing on the guest ?  Also are you able to
reproduce this when running qemu as root user ?

-aneesh

Re: [Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Michael S. Tsirkin]

On Tue, Feb 04, 2014 at 12:51:25PM +0530, Aneesh Kumar K.V wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Mon, Feb 03, 2014 at 03:05:10PM +0530, Aneesh Kumar K.V wrote:
> >> "Michael S. Tsirkin" <mst@redhat.com> writes:
> >> 
> >> > Haven't used 9pfs in a while.
> >> > I thought these patches are a good time to play with it some more.
> >> > I have encountered two issues.
> >> >
> >> > What I'm doing:
> >> > host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.
> >> >
> >> > /scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu kvm64
> >> > -smp 2  f20-x64.qcow2  -netdev user,id=foo -redir tcp:8022::22 -device
> >> > virtio-net,netdev=foo  -serial stdio -fsdev
> >> > local,security_model=none,id=fsdev0,path=/lib/modules/ -device
> >> > virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
> >> > local,security_model=none,id=fsdev1,path=/boot -device
> >> > virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
> >> > -snapshot
> >> >
> >> > guest: Fedora 20
> >> >
> >> > added this in /etc/fstab:
> >> >
> >> > bootshare       /share/boot     9p      trans=virtio,version=9p2000.L 0 0
> >> > libmodulesshare /share/lib/modules      9p trans=virtio,version=9p2000.L 0 0
> >> >
> >> >
> >> > I have encountered two issues:
> >> >
> >> > 1. mount failure on boot
> >> > If I try to mount on boot through fstab, I get:
> >> > [    2.270157] 9pnet: Could not find request transport: virtio
> >> > [    2.270158] 9pnet: Could not find request transport: virtio
> >> 
> >> 
> >> Missing 9pnet_virtio.ko module ? 
> >
> > Maybe it's loaded too late. But when I get to plymouth prompt
> > it's loaded fine.

Any idea about this one? Do you have guests with 9pfs
and virtio as modules and 9pfs mounted from /etc/fstab?

> >> >
> >> > If I then re-try mount, it succeeds immediately!
> >> >
> >> > Some kind of dependency issue?
> >> >
> >> > 2. files immediately in the mounted directory aren't visible on the
> >> > guest under /share/boot.
> >> > For example, files under /boot on host are not visible
> >> > on guest, files under child directories seem visible.
> >> 
> >> 
> >> can you share more details on this ? /boot permissions. ls -al output on
> >> host etc.
> >> 
> >> -aneesh
> >
> > for /boot:
> > dr-xr-xr-x. 7 root root 12288 Feb  2 23:41 /boot/
> >
> > $ ls -la
> > total 739740
> > dr-xr-xr-x.  7 root root    12288 Feb  2 23:41 .
> > dr-xr-xr-x. 22 root root     4096 Feb  2 19:16 ..
> > -rw-r--r--.  1 root root   138741 Dec 23 19:19 config-3.12.6-200.fc19.i686
> > -rw-r--r--.  1 root root   138724 Jan 10 18:06 config-3.12.7-200.fc19.i686
> > -rw-r--r--.  1 root root   138724 Jan 16 06:43
> > config-3.12.8-200.fc19.i686
> 
> 
> Related to SELinux errors ? can you double check you don't selinux
> errors.

No, I didn't see any selinux errors.
Also was able to stat and read files as a regular user.

> Can you also share the file listing on the guest ?

Interestingly, the problem seems to be partially gone.
Not sure what did I change
What I do still see now is this:

Host:
$ ls -l /boot/initramfs-3.11.0-rc5-mst.img
-rw-------. 1 root root 7659204 Aug 18 13:21 /boot/initramfs-3.11.0-rc5-mst.img
Guest:
ls -l /share/initramfs-3.11.0-rc5-mst.img 
ls: cannot access /share/initramfs-3.11.0-rc5-mst.img: Permission denied




>  Also are you able to
> reproduce this when running qemu as root user ?
> 
> -aneesh

Re: [Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Aneesh Kumar K.V]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Tue, Feb 04, 2014 at 12:51:25PM +0530, Aneesh Kumar K.V wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> 
>> > On Mon, Feb 03, 2014 at 03:05:10PM +0530, Aneesh Kumar K.V wrote:
>> >> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> >> 
>> >> > Haven't used 9pfs in a while.
>> >> > I thought these patches are a good time to play with it some more.
>> >> > I have encountered two issues.
>> >> >
>> >> > What I'm doing:
>> >> > host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.
>> >> >
>> >> > /scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu kvm64
>> >> > -smp 2  f20-x64.qcow2  -netdev user,id=foo -redir tcp:8022::22 -device
>> >> > virtio-net,netdev=foo  -serial stdio -fsdev
>> >> > local,security_model=none,id=fsdev0,path=/lib/modules/ -device
>> >> > virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
>> >> > local,security_model=none,id=fsdev1,path=/boot -device
>> >> > virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
>> >> > -snapshot
>> >> >
>> >> > guest: Fedora 20
>> >> >
>> >> > added this in /etc/fstab:
>> >> >
>> >> > bootshare       /share/boot     9p      trans=virtio,version=9p2000.L 0 0
>> >> > libmodulesshare /share/lib/modules      9p trans=virtio,version=9p2000.L 0 0
>> >> >
>> >> >
>> >> > I have encountered two issues:
>> >> >
>> >> > 1. mount failure on boot
>> >> > If I try to mount on boot through fstab, I get:
>> >> > [    2.270157] 9pnet: Could not find request transport: virtio
>> >> > [    2.270158] 9pnet: Could not find request transport: virtio
>> >> 
>> >> 
>> >> Missing 9pnet_virtio.ko module ? 
>> >
>> > Maybe it's loaded too late. But when I get to plymouth prompt
>> > it's loaded fine.
>
> Any idea about this one? Do you have guests with 9pfs
> and virtio as modules and 9pfs mounted from /etc/fstab?

No, I generally have everything builtin for guest. 

>
>> >> >
>> >> > If I then re-try mount, it succeeds immediately!
>> >> >
>> >> > Some kind of dependency issue?
>> >> >
>> >> > 2. files immediately in the mounted directory aren't visible on the
>> >> > guest under /share/boot.
>> >> > For example, files under /boot on host are not visible
>> >> > on guest, files under child directories seem visible.
>> >> 
>> >> 
>> >> can you share more details on this ? /boot permissions. ls -al output on
>> >> host etc.
>> >> 
>> >> -aneesh
>> >
>> > for /boot:
>> > dr-xr-xr-x. 7 root root 12288 Feb  2 23:41 /boot/
>> >
>> > $ ls -la
>> > total 739740
>> > dr-xr-xr-x.  7 root root    12288 Feb  2 23:41 .
>> > dr-xr-xr-x. 22 root root     4096 Feb  2 19:16 ..
>> > -rw-r--r--.  1 root root   138741 Dec 23 19:19 config-3.12.6-200.fc19.i686
>> > -rw-r--r--.  1 root root   138724 Jan 10 18:06 config-3.12.7-200.fc19.i686
>> > -rw-r--r--.  1 root root   138724 Jan 16 06:43
>> > config-3.12.8-200.fc19.i686
>> 
>> 
>> Related to SELinux errors ? can you double check you don't selinux
>> errors.
>
> No, I didn't see any selinux errors.
> Also was able to stat and read files as a regular user.
>
>> Can you also share the file listing on the guest ?
>
> Interestingly, the problem seems to be partially gone.
> Not sure what did I change
> What I do still see now is this:
>
> Host:
> $ ls -l /boot/initramfs-3.11.0-rc5-mst.img
> -rw-------. 1 root root 7659204 Aug 18 13:21 /boot/initramfs-3.11.0-rc5-mst.img
> Guest:
> ls -l /share/initramfs-3.11.0-rc5-mst.img 
> ls: cannot access /share/initramfs-3.11.0-rc5-mst.img: Permission denied
>
>

So you are able to stat the file as the same user the qemu is running
?. That is strange. I am not able to reproduce the problem. You could
possibly instrument the virtio-9p-local.c and see the exact error ?

-aneesh

Re: [Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Michael S. Tsirkin]

On Thu, Feb 06, 2014 at 06:28:32PM +0530, Aneesh Kumar K.V wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Tue, Feb 04, 2014 at 12:51:25PM +0530, Aneesh Kumar K.V wrote:
> >> "Michael S. Tsirkin" <mst@redhat.com> writes:
> >> 
> >> > On Mon, Feb 03, 2014 at 03:05:10PM +0530, Aneesh Kumar K.V wrote:
> >> >> "Michael S. Tsirkin" <mst@redhat.com> writes:
> >> >> 
> >> >> > Haven't used 9pfs in a while.
> >> >> > I thought these patches are a good time to play with it some more.
> >> >> > I have encountered two issues.
> >> >> >
> >> >> > What I'm doing:
> >> >> > host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.
> >> >> >
> >> >> > /scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu kvm64
> >> >> > -smp 2  f20-x64.qcow2  -netdev user,id=foo -redir tcp:8022::22 -device
> >> >> > virtio-net,netdev=foo  -serial stdio -fsdev
> >> >> > local,security_model=none,id=fsdev0,path=/lib/modules/ -device
> >> >> > virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
> >> >> > local,security_model=none,id=fsdev1,path=/boot -device
> >> >> > virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
> >> >> > -snapshot
> >> >> >
> >> >> > guest: Fedora 20
> >> >> >
> >> >> > added this in /etc/fstab:
> >> >> >
> >> >> > bootshare       /share/boot     9p      trans=virtio,version=9p2000.L 0 0
> >> >> > libmodulesshare /share/lib/modules      9p trans=virtio,version=9p2000.L 0 0
> >> >> >
> >> >> >
> >> >> > I have encountered two issues:
> >> >> >
> >> >> > 1. mount failure on boot
> >> >> > If I try to mount on boot through fstab, I get:
> >> >> > [    2.270157] 9pnet: Could not find request transport: virtio
> >> >> > [    2.270158] 9pnet: Could not find request transport: virtio
> >> >> 
> >> >> 
> >> >> Missing 9pnet_virtio.ko module ? 
> >> >
> >> > Maybe it's loaded too late. But when I get to plymouth prompt
> >> > it's loaded fine.
> >
> > Any idea about this one? Do you have guests with 9pfs
> > and virtio as modules and 9pfs mounted from /etc/fstab?
> 
> No, I generally have everything builtin for guest. 

Heh that's the problem then :)
Try making it modular and I think you will see the problem.

> >
> >> >> >
> >> >> > If I then re-try mount, it succeeds immediately!
> >> >> >
> >> >> > Some kind of dependency issue?
> >> >> >
> >> >> > 2. files immediately in the mounted directory aren't visible on the
> >> >> > guest under /share/boot.
> >> >> > For example, files under /boot on host are not visible
> >> >> > on guest, files under child directories seem visible.
> >> >> 
> >> >> 
> >> >> can you share more details on this ? /boot permissions. ls -al output on
> >> >> host etc.
> >> >> 
> >> >> -aneesh
> >> >
> >> > for /boot:
> >> > dr-xr-xr-x. 7 root root 12288 Feb  2 23:41 /boot/
> >> >
> >> > $ ls -la
> >> > total 739740
> >> > dr-xr-xr-x.  7 root root    12288 Feb  2 23:41 .
> >> > dr-xr-xr-x. 22 root root     4096 Feb  2 19:16 ..
> >> > -rw-r--r--.  1 root root   138741 Dec 23 19:19 config-3.12.6-200.fc19.i686
> >> > -rw-r--r--.  1 root root   138724 Jan 10 18:06 config-3.12.7-200.fc19.i686
> >> > -rw-r--r--.  1 root root   138724 Jan 16 06:43
> >> > config-3.12.8-200.fc19.i686
> >> 
> >> 
> >> Related to SELinux errors ? can you double check you don't selinux
> >> errors.
> >
> > No, I didn't see any selinux errors.
> > Also was able to stat and read files as a regular user.
> >
> >> Can you also share the file listing on the guest ?
> >
> > Interestingly, the problem seems to be partially gone.
> > Not sure what did I change
> > What I do still see now is this:
> >
> > Host:
> > $ ls -l /boot/initramfs-3.11.0-rc5-mst.img
> > -rw-------. 1 root root 7659204 Aug 18 13:21 /boot/initramfs-3.11.0-rc5-mst.img
> > Guest:
> > ls -l /share/initramfs-3.11.0-rc5-mst.img 
> > ls: cannot access /share/initramfs-3.11.0-rc5-mst.img: Permission denied
> >
> >
> 
> So you are able to stat the file as the same user the qemu is running
> ?. That is strange. I am not able to reproduce the problem. You could
> possibly instrument the virtio-9p-local.c and see the exact error ?
> 
> -aneesh

Sure, send me debug patch I'll apply and try it.

-- 
MST

Re: [Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Greg Kurz]

On Wed, 5 Feb 2014 23:31:11 +0200
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, Feb 04, 2014 at 12:51:25PM +0530, Aneesh Kumar K.V wrote:
> > "Michael S. Tsirkin" <mst@redhat.com> writes:
> > 
> > > On Mon, Feb 03, 2014 at 03:05:10PM +0530, Aneesh Kumar K.V wrote:
> > >> "Michael S. Tsirkin" <mst@redhat.com> writes:
> > >> 
> > >> > Haven't used 9pfs in a while.
> > >> > I thought these patches are a good time to play with it some more.
> > >> > I have encountered two issues.
> > >> >
> > >> > What I'm doing:
> > >> > host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.
> > >> >
> > >> > /scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu
> > >> > kvm64 -smp 2  f20-x64.qcow2  -netdev user,id=foo -redir
> > >> > tcp:8022::22 -device virtio-net,netdev=foo  -serial stdio -fsdev
> > >> > local,security_model=none,id=fsdev0,path=/lib/modules/ -device
> > >> > virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
> > >> > local,security_model=none,id=fsdev1,path=/boot -device
> > >> > virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
> > >> > -snapshot
> > >> >
> > >> > guest: Fedora 20
> > >> >
> > >> > added this in /etc/fstab:
> > >> >
> > >> > bootshare       /share/boot     9p
> > >> > trans=virtio,version=9p2000.L 0 0
> > >> > libmodulesshare /share/lib/modules      9p
> > >> > trans=virtio,version=9p2000.L 0 0
> > >> >
> > >> >
> > >> > I have encountered two issues:
> > >> >
> > >> > 1. mount failure on boot
> > >> > If I try to mount on boot through fstab, I get:
> > >> > [    2.270157] 9pnet: Could not find request transport: virtio
> > >> > [    2.270158] 9pnet: Could not find request transport: virtio
> > >> 
> > >> 
> > >> Missing 9pnet_virtio.ko module ? 
> > >
> > > Maybe it's loaded too late. But when I get to plymouth prompt
> > > it's loaded fine.
> 
> Any idea about this one? Do you have guests with 9pfs
> and virtio as modules and 9pfs mounted from /etc/fstab?
> 

Hi Michael,

I had the very same problem. You probably need to add 9pnet_virtio to the
initramfs. 

# mkinitrd -f --with=9pnet_virtio /boot/initramfs-$(uname -r).img $(uname -r)
# gzip -dc /boot/initramfs-$(uname -r).img | cpio -t | grep 9pnet
usr/lib/modules/3.11.7-200.fc19.ppc64p7/kernel/net/9p/9pnet_virtio.ko
usr/lib/modules/3.11.7-200.fc19.ppc64p7/kernel/net/9p/9pnet.ko

Cheers.

-- 
Gregory Kurz                                     kurzgreg@fr.ibm.com
                                                 gkurz@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

Re: [Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Michael S. Tsirkin]

On Fri, Feb 07, 2014 at 10:02:52AM +0100, Greg Kurz wrote:
> On Wed, 5 Feb 2014 23:31:11 +0200
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Tue, Feb 04, 2014 at 12:51:25PM +0530, Aneesh Kumar K.V wrote:
> > > "Michael S. Tsirkin" <mst@redhat.com> writes:
> > > 
> > > > On Mon, Feb 03, 2014 at 03:05:10PM +0530, Aneesh Kumar K.V wrote:
> > > >> "Michael S. Tsirkin" <mst@redhat.com> writes:
> > > >> 
> > > >> > Haven't used 9pfs in a while.
> > > >> > I thought these patches are a good time to play with it some more.
> > > >> > I have encountered two issues.
> > > >> >
> > > >> > What I'm doing:
> > > >> > host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.
> > > >> >
> > > >> > /scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu
> > > >> > kvm64 -smp 2  f20-x64.qcow2  -netdev user,id=foo -redir
> > > >> > tcp:8022::22 -device virtio-net,netdev=foo  -serial stdio -fsdev
> > > >> > local,security_model=none,id=fsdev0,path=/lib/modules/ -device
> > > >> > virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
> > > >> > local,security_model=none,id=fsdev1,path=/boot -device
> > > >> > virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
> > > >> > -snapshot
> > > >> >
> > > >> > guest: Fedora 20
> > > >> >
> > > >> > added this in /etc/fstab:
> > > >> >
> > > >> > bootshare       /share/boot     9p
> > > >> > trans=virtio,version=9p2000.L 0 0
> > > >> > libmodulesshare /share/lib/modules      9p
> > > >> > trans=virtio,version=9p2000.L 0 0
> > > >> >
> > > >> >
> > > >> > I have encountered two issues:
> > > >> >
> > > >> > 1. mount failure on boot
> > > >> > If I try to mount on boot through fstab, I get:
> > > >> > [    2.270157] 9pnet: Could not find request transport: virtio
> > > >> > [    2.270158] 9pnet: Could not find request transport: virtio
> > > >> 
> > > >> 
> > > >> Missing 9pnet_virtio.ko module ? 
> > > >
> > > > Maybe it's loaded too late. But when I get to plymouth prompt
> > > > it's loaded fine.
> > 
> > Any idea about this one? Do you have guests with 9pfs
> > and virtio as modules and 9pfs mounted from /etc/fstab?
> > 
> 
> Hi Michael,
> 
> I had the very same problem. You probably need to add 9pnet_virtio to the
> initramfs. 
> 
> # mkinitrd -f --with=9pnet_virtio /boot/initramfs-$(uname -r).img $(uname -r)
> # gzip -dc /boot/initramfs-$(uname -r).img | cpio -t | grep 9pnet
> usr/lib/modules/3.11.7-200.fc19.ppc64p7/kernel/net/9p/9pnet_virtio.ko
> usr/lib/modules/3.11.7-200.fc19.ppc64p7/kernel/net/9p/9pnet.ko
> 
> Cheers.

Yes - it's not in initramfs but why does it
have to be present there?

I am not trying to boot from that, and
*something* loads it after boot:

9pnet_virtio           17488  0 
9pnet                  73304  1 9pnet_virtio



> Gregory Kurz                                     kurzgreg@fr.ibm.com
>                                                  gkurz@linux.vnet.ibm.com
> Software Engineer @ IBM/Meiosys                  http://www.ibm.com
> Tel +33 (0)562 165 496
> 
> "Anarchy is about taking complete responsibility for yourself."
>         Alan Moore.

Re: [Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Michael S. Tsirkin]

On Fri, Feb 07, 2014 at 10:02:52AM +0100, Greg Kurz wrote:
> On Wed, 5 Feb 2014 23:31:11 +0200
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Tue, Feb 04, 2014 at 12:51:25PM +0530, Aneesh Kumar K.V wrote:
> > > "Michael S. Tsirkin" <mst@redhat.com> writes:
> > > 
> > > > On Mon, Feb 03, 2014 at 03:05:10PM +0530, Aneesh Kumar K.V wrote:
> > > >> "Michael S. Tsirkin" <mst@redhat.com> writes:
> > > >> 
> > > >> > Haven't used 9pfs in a while.
> > > >> > I thought these patches are a good time to play with it some more.
> > > >> > I have encountered two issues.
> > > >> >
> > > >> > What I'm doing:
> > > >> > host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.
> > > >> >
> > > >> > /scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu
> > > >> > kvm64 -smp 2  f20-x64.qcow2  -netdev user,id=foo -redir
> > > >> > tcp:8022::22 -device virtio-net,netdev=foo  -serial stdio -fsdev
> > > >> > local,security_model=none,id=fsdev0,path=/lib/modules/ -device
> > > >> > virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
> > > >> > local,security_model=none,id=fsdev1,path=/boot -device
> > > >> > virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
> > > >> > -snapshot
> > > >> >
> > > >> > guest: Fedora 20
> > > >> >
> > > >> > added this in /etc/fstab:
> > > >> >
> > > >> > bootshare       /share/boot     9p
> > > >> > trans=virtio,version=9p2000.L 0 0
> > > >> > libmodulesshare /share/lib/modules      9p
> > > >> > trans=virtio,version=9p2000.L 0 0
> > > >> >
> > > >> >
> > > >> > I have encountered two issues:
> > > >> >
> > > >> > 1. mount failure on boot
> > > >> > If I try to mount on boot through fstab, I get:
> > > >> > [    2.270157] 9pnet: Could not find request transport: virtio
> > > >> > [    2.270158] 9pnet: Could not find request transport: virtio
> > > >> 
> > > >> 
> > > >> Missing 9pnet_virtio.ko module ? 
> > > >
> > > > Maybe it's loaded too late. But when I get to plymouth prompt
> > > > it's loaded fine.
> > 
> > Any idea about this one? Do you have guests with 9pfs
> > and virtio as modules and 9pfs mounted from /etc/fstab?
> > 
> 
> Hi Michael,
> 
> I had the very same problem. You probably need to add 9pnet_virtio to the
> initramfs. 
> 
> # mkinitrd -f --with=9pnet_virtio /boot/initramfs-$(uname -r).img $(uname -r)
> # gzip -dc /boot/initramfs-$(uname -r).img | cpio -t | grep 9pnet
> usr/lib/modules/3.11.7-200.fc19.ppc64p7/kernel/net/9p/9pnet_virtio.ko
> usr/lib/modules/3.11.7-200.fc19.ppc64p7/kernel/net/9p/9pnet.ko
> 
> Cheers.

This seems to help but why is this necessary
in the initrd?
After all I am not trying to boot from 9pfs.


> -- 
> Gregory Kurz                                     kurzgreg@fr.ibm.com
>                                                  gkurz@linux.vnet.ibm.com
> Software Engineer @ IBM/Meiosys                  http://www.ibm.com
> Tel +33 (0)562 165 496
> 
> "Anarchy is about taking complete responsibility for yourself."
>         Alan Moore.

Re: [Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Greg Kurz]

On Wed, 12 Mar 2014 13:34:44 +0200
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Fri, Feb 07, 2014 at 10:02:52AM +0100, Greg Kurz wrote:
> > On Wed, 5 Feb 2014 23:31:11 +0200
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > On Tue, Feb 04, 2014 at 12:51:25PM +0530, Aneesh Kumar K.V wrote:
> > > > "Michael S. Tsirkin" <mst@redhat.com> writes:
> > > > 
> > > > > On Mon, Feb 03, 2014 at 03:05:10PM +0530, Aneesh Kumar K.V wrote:
> > > > >> "Michael S. Tsirkin" <mst@redhat.com> writes:
> > > > >> 
> > > > >> > Haven't used 9pfs in a while.
> > > > >> > I thought these patches are a good time to play with it some more.
> > > > >> > I have encountered two issues.
> > > > >> >
> > > > >> > What I'm doing:
> > > > >> > host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.
> > > > >> >
> > > > >> > /scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu
> > > > >> > kvm64 -smp 2  f20-x64.qcow2  -netdev user,id=foo -redir
> > > > >> > tcp:8022::22 -device virtio-net,netdev=foo  -serial stdio -fsdev
> > > > >> > local,security_model=none,id=fsdev0,path=/lib/modules/ -device
> > > > >> > virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
> > > > >> > local,security_model=none,id=fsdev1,path=/boot -device
> > > > >> > virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
> > > > >> > -snapshot
> > > > >> >
> > > > >> > guest: Fedora 20
> > > > >> >
> > > > >> > added this in /etc/fstab:
> > > > >> >
> > > > >> > bootshare       /share/boot     9p
> > > > >> > trans=virtio,version=9p2000.L 0 0
> > > > >> > libmodulesshare /share/lib/modules      9p
> > > > >> > trans=virtio,version=9p2000.L 0 0
> > > > >> >
> > > > >> >
> > > > >> > I have encountered two issues:
> > > > >> >
> > > > >> > 1. mount failure on boot
> > > > >> > If I try to mount on boot through fstab, I get:
> > > > >> > [    2.270157] 9pnet: Could not find request transport: virtio
> > > > >> > [    2.270158] 9pnet: Could not find request transport: virtio
> > > > >> 
> > > > >> 
> > > > >> Missing 9pnet_virtio.ko module ? 
> > > > >
> > > > > Maybe it's loaded too late. But when I get to plymouth prompt
> > > > > it's loaded fine.
> > > 
> > > Any idea about this one? Do you have guests with 9pfs
> > > and virtio as modules and 9pfs mounted from /etc/fstab?
> > > 
> > 
> > Hi Michael,
> > 
> > I had the very same problem. You probably need to add 9pnet_virtio to the
> > initramfs. 
> > 
> > # mkinitrd -f --with=9pnet_virtio /boot/initramfs-$(uname -r).img $(uname -r)
> > # gzip -dc /boot/initramfs-$(uname -r).img | cpio -t | grep 9pnet
> > usr/lib/modules/3.11.7-200.fc19.ppc64p7/kernel/net/9p/9pnet_virtio.ko
> > usr/lib/modules/3.11.7-200.fc19.ppc64p7/kernel/net/9p/9pnet.ko
> > 
> > Cheers.
> 
> This seems to help but why is this necessary
> in the initrd?
> After all I am not trying to boot from 9pfs.
> 

I do not know... maybe it has to do with the way systemd deals with fstab... :-\

> 
> > -- 
> > Gregory Kurz                                     kurzgreg@fr.ibm.com
> >                                                  gkurz@linux.vnet.ibm.com
> > Software Engineer @ IBM/Meiosys                  http://www.ibm.com
> > Tel +33 (0)562 165 496
> > 
> > "Anarchy is about taking complete responsibility for yourself."
> >         Alan Moore.
> 



-- 
Gregory Kurz                                     kurzgreg@fr.ibm.com
                                                 gkurz@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

Re: [Qemu-devel] 9pfs troubles (was Re: [PATCH 1/4] hw/9pfs: fix error handing in local_ioc_getversion())

[Marc-André Lureau]

Hi

On Mon, Mar 17, 2014 at 10:12 AM, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
> On Wed, 12 Mar 2014 13:34:44 +0200
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> On Fri, Feb 07, 2014 at 10:02:52AM +0100, Greg Kurz wrote:
>> > On Wed, 5 Feb 2014 23:31:11 +0200
>> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> > > On Tue, Feb 04, 2014 at 12:51:25PM +0530, Aneesh Kumar K.V wrote:
>> > > > "Michael S. Tsirkin" <mst@redhat.com> writes:
>> > > >
>> > > > > On Mon, Feb 03, 2014 at 03:05:10PM +0530, Aneesh Kumar K.V wrote:
>> > > > >> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> > > > >>
>> > > > >> > Haven't used 9pfs in a while.
>> > > > >> > I thought these patches are a good time to play with it some more.
>> > > > >> > I have encountered two issues.
>> > > > >> >
>> > > > >> > What I'm doing:
>> > > > >> > host: qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10.
>> > > > >> >
>> > > > >> > /scm/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1g -cpu
>> > > > >> > kvm64 -smp 2  f20-x64.qcow2  -netdev user,id=foo -redir
>> > > > >> > tcp:8022::22 -device virtio-net,netdev=foo  -serial stdio -fsdev
>> > > > >> > local,security_model=none,id=fsdev0,path=/lib/modules/ -device
>> > > > >> > virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=libmodulesshare -fsdev
>> > > > >> > local,security_model=none,id=fsdev1,path=/boot -device
>> > > > >> > virtio-9p-pci,id=fs1,fsdev=fsdev0,mount_tag=bootshare -no-reboot
>> > > > >> > -snapshot
>> > > > >> >
>> > > > >> > guest: Fedora 20
>> > > > >> >
>> > > > >> > added this in /etc/fstab:
>> > > > >> >
>> > > > >> > bootshare       /share/boot     9p
>> > > > >> > trans=virtio,version=9p2000.L 0 0
>> > > > >> > libmodulesshare /share/lib/modules      9p
>> > > > >> > trans=virtio,version=9p2000.L 0 0
>> > > > >> >
>> > > > >> >
>> > > > >> > I have encountered two issues:
>> > > > >> >
>> > > > >> > 1. mount failure on boot
>> > > > >> > If I try to mount on boot through fstab, I get:
>> > > > >> > [    2.270157] 9pnet: Could not find request transport: virtio
>> > > > >> > [    2.270158] 9pnet: Could not find request transport: virtio
>> > > > >>
>> > > > >>
>> > > > >> Missing 9pnet_virtio.ko module ?
>> > > > >
>> > > > > Maybe it's loaded too late. But when I get to plymouth prompt
>> > > > > it's loaded fine.
>> > >
>> > > Any idea about this one? Do you have guests with 9pfs
>> > > and virtio as modules and 9pfs mounted from /etc/fstab?
>> > >
>> >
>> > Hi Michael,
>> >
>> > I had the very same problem. You probably need to add 9pnet_virtio to the
>> > initramfs.
>> >
>> > # mkinitrd -f --with=9pnet_virtio /boot/initramfs-$(uname -r).img $(uname -r)
>> > # gzip -dc /boot/initramfs-$(uname -r).img | cpio -t | grep 9pnet
>> > usr/lib/modules/3.11.7-200.fc19.ppc64p7/kernel/net/9p/9pnet_virtio.ko
>> > usr/lib/modules/3.11.7-200.fc19.ppc64p7/kernel/net/9p/9pnet.ko
>> >
>> > Cheers.
>>
>> This seems to help but why is this necessary
>> in the initrd?
>> After all I am not trying to boot from 9pfs.
>>
>
> I do not know... maybe it has to do with the way systemd deals with fstab... :-\
>

I reached the same issue, I opened a bug for systemd in f21
https://bugzilla.redhat.com/show_bug.cgi?id=1184122

-- 
Marc-André Lureau