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

[Gleb Natapov]

On Tue, Aug 06, 2013 at 10:45:01AM +0200, Andreas Färber wrote:
> Am 06.08.2013 10:36, schrieb Gleb Natapov:
> > 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.
> > 
> >> Besides, both -device pvpanic and use of ioport=0 to disable it
> >> are completely undocumented.
> >>
> > Not the only undocumented thing in QEMU command line :)
> [snip]
> 
> I disagree: -device adds a device, not removes one. It will still be
> present.
> 
I assume you are answering to the quote about ioport=0, not
documentation here. ioport=0 does not removes the device, it disables
it. The claim was it cannot be disabled, it can (assuming no bugs), but
it should not be.

> I am neutral as to whether qemu-system-x86_64 should have it enabled by
> default or not. But if we want to suppress it, then -nodefaults should
> disable it. Since libvirt uses that though, it would mean libvirt would
> need to add it back, whether via user's XML domain config or by libvirt
> itself based on some version/etc. heuristics.
> 
There is no clear definition of what -nodefaults should or should not
do. Should it disable PV ACPI hotplug device? Should it create a machine
with no mmio/io regions registered at all?

--
			Gleb.