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

[Gleb Natapov]

On Tue, Aug 06, 2013 at 03:08:32PM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 06, 2013 at 02:00:35PM +0300, Gleb Natapov wrote:
> > On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
> > > Am 06.08.2013 11:32, schrieb Gleb Natapov:
> > > > 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:
> > > >>>>>> 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?
> > > 
> > > You misunderstand: -device pvpanic,? will document that there is a
> > > numeric port property, which as such is self-documenting. But there's no
> > Yes, this is how I found it.
> > 
> > > way for us to document there that port=0 has special meaning of "disable
> > > this device in ACPI".
> > > 
> > Adding capability to describe a property should solve that and is a good
> > idea regardless, no? "pvpanic.ioport=uint16" is not very descriptive.
> > 
> > 
> > > Disabling a device usually requires to not include that device (or in
> > > the future to "unrealize" it), which would require some way to suppress
> > > having the device created internally by default. As done for floppy,
> > > serial, etc. devices in x86 IIUC, which are in the same PIO situation as
> > > the pvpanic device, except that they represent physical devices.
> > > Adding some -no-pvpanic switch might be an alternative. And if not done
> > > already, disabling the pvpanic device should definitely be documented
> > > for the man page.
> > We should not add -no-pvpanic! If there is a legitimate use for
> > -no-pvpanic we should go with MST suggestion and do not create it by
> > default. The question is why would anyone use -no-pvpanic? Legit reason,
> > not just "to remove pvpanic".
> 
> To be able to emulate a real hardware system without any PV devices.
> I think it's a reasonable requirement.
> 
Qemu is so far from able to do so that I do not consider it such.

--
                        Gleb.