Red Hat Bugzilla – Bug 591763
Guest quits abnormally during write 'zero' to port 49220
Last modified: 2015-05-24 20:05:32 EDT
Description of problem:
Enumerate all IO port ranges through /proc/ioports, and try to read/write random port, Reset guest when test detects the hang.
I found guest always quits abnormally during write 'zero' to port 49220. qemu process outputs "virtio-net header not in first element".
This bug is only reproduced when using virtio nic.
Version-Release number of selected component (if applicable):
guest kernel: 2.6.18-196.el5
host kernel: 2.6.32-24.el6.x86_64
# rpm -qa |grep qemu
Steps to Reproduce:
1.boot up a guest with virtio_nic
2.try to write 'zero' to port 49220
# echo -e '\0' | dd of=/dev/port seek=49220 bs=1 count=1
guest quits abnormally
guest works well or hangs
1. command line:
# qemu-kvm -name 'vm1' -monitor tcp:0:6001,server,nowait -drive file=/root/autotest/client/tests/kvm/images/RHEL-Server-5.5-64-virtio.qcow2,if=virtio,cache=none,boot=on -net nic,vlan=0,model=virtio,macaddr=00:A9:7C:6C:47:11 -net tap,vlan=0,ifname=virtio_0_6001,script=/root/autotest/client/tests/kvm/scripts/qemu-ifup-switch,downscript=no -m 512 -smp 1 -soundhw ac97 -usbdevice tablet -rtc-td-hack -no-hpet -cpu qemu64,+sse2 -no-kvm-pit-reinjection -redir tcp:5000::22 -vnc :0 -serial unix:/tmp/serial-20100513-104022-p4ix,server,nowait
(qemu)virtio-net header not in first element
2. ioports info of guest
guest)# cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vga+
03f2-03f5 : floppy
03f7-03f7 : floppy DIR
03f8-03ff : serial
0cf8-0cff : PCI conf1
afe0-afe3 : ACPI GPE0_BLK
b000-b03f : 0000:00:01.3
b000-b003 : ACPI PM1a_EVT_BLK
b004-b005 : ACPI PM1a_CNT_BLK
b008-b00b : ACPI PM_TMR
b010-b015 : ACPI CPU throttle
b100-b10f : 0000:00:01.3
b100-b107 : piix4_smbus
c000-c00f : 0000:00:01.1
c000-c007 : ide0
c008-c00f : ide1
c020-c03f : 0000:00:01.2
c020-c03f : uhci_hcd
c040-c05f : 0000:00:03.0
c040-c05f : virtio-pci
c400-c7ff : 0000:00:04.0
c400-c7ff : Intel 82801AA-ICH
c800-c8ff : 0000:00:04.0
c800-c8ff : Intel 82801AA-ICH
c900-c93f : 0000:00:05.0
c900-c93f : virtio-pci
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
Is this really a valid test? You're writing 0 to ioport 0xc044, which is clearly assigned to virtio-pci. There are control structures there that get out of sync if modified outside the driver. Surely there could be instances of real hardware behaving the same way or worse if a privileged user decides to start poking io space.
I found this 'bug' by execute the iofuzz testcase of autotest, and verified manually.
The design of iofuzz is simple: it just generate random I/O port
activity inside the virtual machine. The correctness of the device
emulation may be verified through this test.
As the instructions are randomly generated, guest may enter the wrong
state. The test solve this issue by detect the hang and restart the
The test duration could also be adjusted through the "fuzz_count". And
the parameter "skip_devices" is used to specified the devices which
should not be used to do the fuzzing.
For current version, every activity were logged and the command was
sent through a session between host and guest. Through this method may
slow down the whole test but it works well. The enumeration was done
through /proc/ioports and the scenario of activity is not aggressive.
Thanks Amos, so if I understand the test, the failing condition is that qemu exists rather than simply restarting the vm, which is considered acceptable.
IMO it is rather low priority, it's not a huge difference between guest crash and reboot. It's not a security issue either to the guest nor the host. I rather close it as won't fix. Amos, please respond if you think otherwise
I suggest to add some fault tolerance for virtio-net rather than a exit().
Recover the virtio device from error state or could inject a interrupt to let the guest know what happens.
just my opinion.
Recovering a guest from such external writes is not possible. It's impossible to maintain all the state that would be necessary to recover from such illegal writes.
I think the point of the test is to write to random locations in the IO space and find out the response of the guest or the hypervisor.
I also think it's perfectly valid for qemu to exit. The testsuite can re-start the VM, as mentioned in the link (the testsuite seems to currently only expect guest hangs, not guest shutdowns, and in that case, the testsuite should be fixed).
I'm not really sure this is a bug, closing as NOTABUG. Please re-open with a different summary line and description if any other behaviour is desired.