Bug 591763
| Summary: | Guest quits abnormally during write 'zero' to port 49220 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Amos Kong <akong> |
| Component: | qemu-kvm | Assignee: | Amit Shah <amit.shah> |
| Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.0 | CC: | ailan, alex.williamson, ndai, tburke, virt-maint |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-06-08 07:17:22 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 580953 | ||
|
Description
Amos Kong
2010-05-13 03:33:11 UTC
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. |