On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
If you see a mouse in a room, how likely is it that there's a single mouse there?
This is a PV technology which to me looks like it was rushed through and not only set on by default, but without a way to disable it - apparently on the assumption there's 0 chance it can cause any damage. Now that we do know the chance it's not there, why not go back to the standard interface, and why not give users a chance to enable/disable it?
You should be able to disable it with: -device pvpanic,ioport=0
Doesn't work for me.
Bug that should be fixed. With this command line _STA should return zero.
It doesn't have anything to do with _STA: device still appears in QOM. It's a QEMU issue, devices that are added with -device are documented in -device help and removed by dropping them from command line. Devices added by default have no way to be dropped from QOM except -nodefaults.
Besides, both -device pvpanic and use of ioport=0 to disable it are completely undocumented.
Not the only undocumented thing in QEMU command line :)
All -device fields are documented with -device help. This was supposed to be the right way to add all new devices.
BTW pls keep qemu-devel Cc'd.
Haven't touched CC list.
We have different definition of "damage" though.
Driver bugs, qemu bugs, OSPM bugs all can cause issues like OS crashes, suspend/resume issues, bad performance ... What's your definition of damage?
None of those cover the case at hand.
Sigh. These examples demonstrate why would user want to run QEMU without the pvpanic device.
-- Gleb.