Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resources

[Laszlo Ersek <lersek@redhat.com>]

On 02/18/14 17:36, Igor Mammedov wrote:
> On Mon, 17 Feb 2014 09:32:35 +0100
> Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
>> On So, 2014-02-16 at 17:53 +0200, Michael S. Tsirkin wrote:
>>> On Fri, Feb 07, 2014 at 01:51:27PM +0100, Igor Mammedov wrote:
>>>> Since introduction of PCIHP, it became problematic to
>>>> punch hole in PCI0._CRS statically since PCI hotplug
>>>> region size became runtime changeable.
>>>
>>> What makes it runtime changeable?
>>
>> machine type.  q35 / piix map them at different locations.
>>
>> Also we might want to this also for devices which are
>> runtime-configurable (isa-debugcon, pvpanic, ...).
> I'd convert simple devices that conditionally enabled at
> startup time, from static definition + patching into
> completely dynamically generated when device present.
> For example pvpanic falls in to this category.
> 
> That would result in smaller ACPI tables guest has to deal with.

I could be mistaken, but AFAIR this caused the windows device manager to
pop up in windows? Ie. if you have a windows guest and cold-boot it
twice, once with the device present (generated into ACPI) and once with
the device absent (not generated into ACPI), then you get hardware
changes. Whereas, if the device is always present and you only patch
_STA, then windows doesn't perceive it as a hw change.

Do I recall it right?...

You could argue that "a new device indeed warrants a device manager
popup", but esp. for isa-debugcon and pvpanic, you might want to enable
those opportunistically, without triggering a new hw dialog. Pvpanic
triggering the device manager was exactly what drew frowns, for its
original implementation. IIRC.

Anyway pls. feel free to ignore this comment, it just crossed my mind.
(And of course it's not related to your series.)

Thanks
Laszlo