On Tue, Aug 06, 2013 at 12:32:47PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote:
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.
You said disabled, not removed.
I really meant disable adding it.
So does -global pvpanic,ioport=0 disables the device for you?
What do you mean by disabled?
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.
Are you saying that because pvpanic is added automatically QEMU -device help does not print help about it? Why not fix that? What QEMU --help issues has to do with deciding which devices should or should not be present by default?
No, I'm saying what I said: that there's no way to remove a device added by default except -nodefaults, and no way to find out what does -nodefaults exclude so you can add things you need back selectively.
We wanted to fix the later issue for a long time, it's hard to fix - that's why we don't fix that. Just using -device for everything is a work-around for now.
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.
He can disable it, but chances the device will cause aforementioned problems are so much smaller (by design mind you) than PV APIC hotplug device that it makes me wonder why haven't you advocate to make PV APIC hotplug device to be configurable with -device too.
This might be a good idea for Q35. We probably want to keep it as is for PIIX for compatibility. Then again, different behaviour for Q35/PIIX might confuse people.
-- Gleb.