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

["Andreas Färber" <afaerber@suse.de>]

Am 06.08.2013 11:20, schrieb 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.

Answering to all of i) additional -device pvpanic,ioport=0 to disable
another one, ii) ioport=0 to disable a certain device and iii) either
being an undocumented feature to disable devices. ;)

"Disabled" here referring both to not in PIO/ACPI/etc. and to not
present in the QOM composition tree.

In the end with pvpanic being an ISADevice, this goes back to my large
series for Hervé's i87312 Super I/O chipset, where we discussed what
would be involved in having a reconfigurable ISADevice not listen on
some port/IRQ. We haven't decided on a solution yet (reconfiguring the
i87312 from guest will assert or be ignored), and I strongly disagree to
the solution of ioport=0 magic as general solution - either we should
use realized=false (which then drops any VMStateDescription from
migration) or revive my earlier attempts to add an explicit boolean
ISADevice::enabled state, which would correspond to EEPROM-based
reconfiguration of the plugged-in ISA card. Which of course would only
help ISADevices but not MMIO-based SysBusDevices...

Andreas

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