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
inclusion.

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.

(http://patchwork.test.kernel.org/patch/2155/)
    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
    virtual machine.
    
    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.