large -initrd can wrap around in memory causing memory corruption

We don't use large -initrd in libguestfs any more, but I noticed that a large -initrd file now crashes qemu spectacularly:

$ ls -lh /tmp/kernel /tmp/initrd 
-rw-r--r--. 1 rjones rjones 273M Jun  3 14:02 /tmp/initrd
lrwxrwxrwx. 1 rjones rjones   35 Jun  3 14:02 /tmp/kernel -> /boot/vmlinuz-3.9.4-200.fc18.x86_64

$ ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \
    -kernel /tmp/kernel -initrd /tmp/initrd -hda /tmp/test1.img -serial stdio \
    -append console=ttyS0

qemu crashes with one of several errors:

PFLASH: Possible BUG - Write block confirm

qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000000b96cd

If -enable-kvm is used:

KVM: injection failed, MSI lost (Operation not permitted)

In all cases the SDL display fills up with coloured blocks before the crash (see the attached screenshot).



I'm using qemu from git (f10acc8b38d65a66ffa0588a036489d7fa6a593e).

One way to reproduce this is to just use a large (200 MB) completely random initrd.  Note this error seems to happen a long time before even the kernel starts up, so the actual content of the initrd doesn't matter.

dd if=/dev/urandom of=/tmp/initrd bs=1M count=200
qemu-system-x86_64 -kernel /boot/vmlinuz -initrd /tmp/initrd -serial stdio -append console=ttyS0

OK I see what's happening.  Because I forgot about the -m option, qemu allocates 128 MB of RAM.  It's obviously wrapping around in memory and overwriting all the low memory.

If you add (eg) -m 1024 it works.

Just saw something similar with qemu 2.2.1:

KVM: injection failed, MSI lost (Input/output error)
qemu-system-x86_64: /home/bart/software/qemu-2.2.1/hw/net/vhost_net.c:264: vhost_net_stop_one: Assertion `r >= 0' failed.
2015-03-23 02:44:44.952+0000: shutting down


Although the error message is the same, the bug in comment 5 seems completely different.  Please open a new bug about this issue, giving *all* details - including the full qemu command line.

Thanks Richard for the quick feedback. A new bug report has been created as https://bugs.launchpad.net/qemu/+bug/1435359.

Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?

The answer is I don't know.  Closing this bug seems correct unless someone can reproduce the original problem.

[Expired for QEMU because there has been no activity for 60 days.]