[SeaBIOS] [PATCH] don't expose pvpanic device in the UI

[Michael S. Tsirkin]

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.