I figured out the problem. There is zerocopy IO is being done via DMA to
a buffer allocated with valloc(). Right now, I am running a hack-fix
locally so I can get some other stuff done first. I will propose a
proper fix to the list in a few days.
On 11/25/2013 10:49 AM, Richard Yao wrote:
> 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.
>
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
