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.
