[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resourc
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resources |
Date: |
Tue, 18 Feb 2014 23:04:13 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11 |
On 02/18/14 17:36, Igor Mammedov wrote:
> On Mon, 17 Feb 2014 09:32:35 +0100
> Gerd Hoffmann <address@hidden> 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
- Re: [Qemu-devel] [RFC 7/9] acpi: consume CPU hotplug IO resource in PNP0C02 device, (continued)
- [Qemu-devel] [RFC 8/9] pcihp: expose PCI hotplug MMIO base/length as properties of piix4pm, Igor Mammedov, 2014/02/07
- [Qemu-devel] [RFC 9/9] acpi: consume PCIHP IO resource in PNP0C02 device, Igor Mammedov, 2014/02/07
- Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resources, Michael S. Tsirkin, 2014/02/16
- Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resources, Igor Mammedov, 2014/02/18
- Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resources,
Laszlo Ersek <=
- Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resources, Igor Mammedov, 2014/02/19
Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resources, Igor Mammedov, 2014/02/17
Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resources, Gerd Hoffmann, 2014/02/17