[Qemu-devel] QEMU dies on any attempt to load a Linux kernel module when using a 9P rootfs

[Richard Yao]

I booted a Gentoo Linux installation in QEMU with a 9P rootfs as follows:

sudo qemu-kvm -cpu host -m 1024 -kernel
/mnt/test/usr/src/linux-3.13-rc1/arch/x86/boot/bzImage -append
'root=/dev/root rootfstype=9p rootflags=trans=virtio,version=9p2000.L ro
console=ttyS0' -serial stdio -fsdev
local,id=root,path=/mnt/test,security_model=none -device
virtio-9p-pci,fsdev=root,mount_tag=/dev/root

The system boots fine, but attempting to load any module will fail:

localhost ~ # modprobe crc32
qemu-system-x86_64: virtio: trying to map MMIO memory

The behavior is consistent no matter what combination of things that I
try. So far, I have tried Linux 3.10.7-gentoo (Gentoo patchset) and
Linux 3.13-rc1. I have tried QEMU 1.4.2, QEMU 1.6.1 and QEMU HEAD. I
have also tried booting without KVM, but the behavior is the same:

sudo qemu-kvm --no-kvm -m 1024 -kernel
/mnt/test/usr/src/linux-3.13-rc1/arch/x86/boot/bzImage -append
'root=/dev/root rootfstype=9p rootflags=trans=virtio,version=9p2000.L ro
console=ttyS0' -serial stdio -fsdev
local,id=root,path=/mnt/test,security_model=none -device
virtio-9p-pci,fsdev=root,mount_tag=/dev/root

Here is a backtrace of QEMU itself that I obtained using gdb:

Breakpoint 1, virtqueue_map_sg (sg=0x7f695b797b98, addr=0x7f695b793b98,
num_sg=3, is_write=1) at
/usr/src/debug/app-emulation/qemu-9999/qemu-9999/hw/virtio/virtio.c:434
434                 error_report("virtio: trying to map MMIO memory");
(gdb) bt
#0  virtqueue_map_sg (sg=0x7f695b797b98, addr=0x7f695b793b98, num_sg=3,
is_write=1) at
/usr/src/debug/app-emulation/qemu-9999/qemu-9999/hw/virtio/virtio.c:434
#1  0x00000000006eb666 in virtqueue_pop (vq=0x1b23740,
elem=0x7f695b793b88) at
/usr/src/debug/app-emulation/qemu-9999/qemu-9999/hw/virtio/virtio.c:500
#2  0x00000000004a74ee in handle_9p_output (vdev=0x7f695b1fd910,
vq=0x1b23740) at
/usr/src/debug/app-emulation/qemu-9999/qemu-9999/hw/9pfs/virtio-9p.c:3254
#3  0x00000000006ec4b5 in virtio_queue_notify_vq (vq=0x1b23740) at
/usr/src/debug/app-emulation/qemu-9999/qemu-9999/hw/virtio/virtio.c:720
#4  0x00000000006edf65 in virtio_queue_host_notifier_read (n=0x1b23790)
at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/hw/virtio/virtio.c:1116
#5  0x00000000005d3c9c in qemu_iohandler_poll (pollfds=0x1aae200, ret=1)
at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/iohandler.c:143
#6  0x00000000005d4702 in main_loop_wait (nonblocking=0) at
/usr/src/debug/app-emulation/qemu-9999/qemu-9999/main-loop.c:484
#7  0x000000000066c583 in main_loop () at
/usr/src/debug/app-emulation/qemu-9999/qemu-9999/vl.c:2014
#8  0x00000000006730d1 in main (argc=17, argv=0x7fffa93167c8,
envp=0x7fffa9316858) at
/usr/src/debug/app-emulation/qemu-9999/qemu-9999/vl.c:4366

I spoke with Alexander Graf about this in IRC. He suggested that the
guest is passing QEMU a bad address and gave me a small patch to use to
get the VM to stop when this happens so that I could attach gdb and poke
around. Sadly, I was on my way out to dinner when he gave that to me and
I subsequently lost the patch to the Debian's paste bin's garbage
collection. I have tried debugging without it by booting qemu with `-s
-S`, setting break points for the kernel module initialization routines
and running the system, but the breakpoints are not triggering.

If I could get another copy of the patch that Alexander gave me, I would
be able to move forward. Unfortunately, he is not on IRC right now. I
cannot debug any further with my current knowledge, so I am sending what
I know so far to the relevant mailing lists. It would be greatly
appreciated if someone would point me in the right direction (or even
better, send me a patch to fix what is wrong).

P.S. As a side note, there appears to be regression between 3.10.7 and
3.13-rc1. In specific, the rootfs will fail to mount unless I use
mount_tag=/dev/root and pass root=/dev/root. With 3.10.7, I could use an
arbitrary name.

.config
Description: Text document

signature.asc
Description: OpenPGP digital signature