| Message ID | 1390921707-15109-1-git-send-email-kirill.shutemov@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
"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
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.
"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
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
"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
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
"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
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.
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.
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.
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.
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. >
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
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)
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(-)