Discussion:
qemu virtfs 9p not working on arm?
Peter Maydell
2013-08-01 09:43:01 UTC
Permalink
I'm not sure whether this is a kernel problem or a qemu problem (or
even a user problem). The folks on OFTC #qemu suggested I email the
list and relevant section maintainers so that's what I'm doing -- hope
it's okay.
I'm trying to boot qemu-system-arm with rootfs on 9p, and experiencing
You don't say which board model you're using; I guess one
of the PCI ones from the rest of the command line.
| 9pnet: Installing 9P2000 support
| 9pnet_virtio: probe of virtio0 failed with error -2
| VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 4
| rtc-pl031 dev:e8: setting system clock to 2013-07-31 22:56:25 UTC (1375311385)
| 9pnet_virtio: no channels available
| VFS: Cannot open root device "root" or unknown-block(0,0): error -2
| 0b00 1048575 sr0 driver: sr
| Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
That looks like ENOENT during the probe to me, but I can't find where
-append "root=root rw rootflags=rw,trans=virtio,version=9p2000.L -rootfstype=9p"
-fsdev local,id=root,path=$(pwd)/root,security_model=none
-device virtio-9p-pci,fsdev=root,mount_tag=root
and this same configuration seems to work on x86. The kernels I'm
using are from the latest Aboriginal Linux images (3.10) and
/proc/config.gz seems to show that all the 9p/virtfs options are
enabled.
Do other virtio devices work?

-- PMM
Rich Felker
2013-07-31 23:25:26 UTC
Permalink
Hi,

I'm not sure whether this is a kernel problem or a qemu problem (or
even a user problem). The folks on OFTC #qemu suggested I email the
list and relevant section maintainers so that's what I'm doing -- hope
it's okay.

I'm trying to boot qemu-system-arm with rootfs on 9p, and experiencing
the following error:

| 9pnet: Installing 9P2000 support
| 9pnet_virtio: probe of virtio0 failed with error -2
| VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 4
| rtc-pl031 dev:e8: setting system clock to 2013-07-31 22:56:25 UTC (1375311385)
| 9pnet_virtio: no channels available
| VFS: Cannot open root device "root" or unknown-block(0,0): error -2
| Please append a correct "root=" boot option; here are the available partitions:
| 0b00 1048575 sr0 driver: sr
| Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

That looks like ENOENT during the probe to me, but I can't find where
in the kernel source it's coming from. My configuration is:

-append "root=root rw rootflags=rw,trans=virtio,version=9p2000.L -rootfstype=9p"
-fsdev local,id=root,path=$(pwd)/root,security_model=none
-device virtio-9p-pci,fsdev=root,mount_tag=root

and this same configuration seems to work on x86. The kernels I'm
using are from the latest Aboriginal Linux images (3.10) and
/proc/config.gz seems to show that all the 9p/virtfs options are
enabled.

Attempting to mount the filesystem after booting also fails with:

| 9pnet_virtio: no channels available
| mount: mounting root on /mnt/ failed: No such file or directory

I have not tested other targets.

Finally, my version of qemu is 1.5.1 from the Debian packages.

Rich
Rich Felker
2013-08-01 15:59:07 UTC
Permalink
Post by Peter Maydell
I'm not sure whether this is a kernel problem or a qemu problem (or
even a user problem). The folks on OFTC #qemu suggested I email the
list and relevant section maintainers so that's what I'm doing -- hope
it's okay.
I'm trying to boot qemu-system-arm with rootfs on 9p, and experiencing
You don't say which board model you're using; I guess one
of the PCI ones from the rest of the command line.
I'm using -M versatilepb -cpu arm1136-r2, also copied from the
Aboriginal Linux image since that's what the kernel was intended to
run on. I'm on the software side, not the hardware side, so I'm far
from an expert in understanding arm hardware variants. (I'm using qemu
to test software and make sure the arm-specific asm is correct, not to
test deployments.)
Post by Peter Maydell
From what I understand, this board has PCI. However, while doing some
searches based on your question, I found this which may be relevant:

http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg02237.html

Does this sound like it could be the issue?
Post by Peter Maydell
| 9pnet: Installing 9P2000 support
| 9pnet_virtio: probe of virtio0 failed with error -2
| VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 4
| rtc-pl031 dev:e8: setting system clock to 2013-07-31 22:56:25 UTC (1375311385)
| 9pnet_virtio: no channels available
| VFS: Cannot open root device "root" or unknown-block(0,0): error -2
| 0b00 1048575 sr0 driver: sr
| Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
That looks like ENOENT during the probe to me, but I can't find where
-append "root=root rw rootflags=rw,trans=virtio,version=9p2000.L -rootfstype=9p"
-fsdev local,id=root,path=$(pwd)/root,security_model=none
-device virtio-9p-pci,fsdev=root,mount_tag=root
and this same configuration seems to work on x86. The kernels I'm
using are from the latest Aboriginal Linux images (3.10) and
/proc/config.gz seems to show that all the 9p/virtfs options are
enabled.
Do other virtio devices work?
I haven't really tried any devices since my aim is just software
testing, but I could try.

Rich
Peter Maydell
2013-08-01 16:43:39 UTC
Permalink
Post by Rich Felker
I'm using -M versatilepb -cpu arm1136-r2, also copied from the
Aboriginal Linux image since that's what the kernel was intended to
run on. I'm on the software side, not the hardware side, so I'm far
from an expert in understanding arm hardware variants. (I'm using qemu
to test software and make sure the arm-specific asm is correct, not to
test deployments.)
From what I understand, this board has PCI. However, while doing some
http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg02237.html
Does this sound like it could be the issue?
It might be. If so, you'll probably find that other PCI devices
(including but not limited to other virtio devices) also don't
work -- this will be useful in narrowing down whether the problem
is specific to our virtio-9p code somehow (seems unlikely as it
doesn't do anything particularly odd for a virtio device), or
specific to virtio-pci (unlikely again, there's no ARM specific
code at that point) or related to PCI.

The kernel's support for the PCI controller on this board
is definitely known to be pretty buggy and broken, so it's
a strong candidate for the culprit here.

-- PMM

Loading...