Re: [Qemu-devel] [SeaBIOS] [PATCH] don't expose pvpanic device in the UI

[Gleb Natapov <gleb@redhat.com>]

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. So does -global pvpanic,ioport=0
disables the device for you?

> 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?

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

--
			Gleb.