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

[Andreas Färber]

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
way for us to document there that port=0 has special meaning of "disable
this device in ACPI".

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.

To me this is less a concrete problem with Windows guests but a
conceptual question of how we go about enabling/disabling QEMU devices
in a hopefully consistent way.

Writing a driver does not solve it fully, you'd still need to actively
install that driver, same issue as with virtio. virtio is opt-in, so for
customers not using our VM Driver Pack we offer AHCI as driver-less
alternative.

I wonder if IPMI might be such an alternative in the future, in which
case we should come up with some way to fully disable pvpanic device
creation. CC'ing Corey.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg