Re: [Qemu-devel] [PATCH 09/11] ACPI: move PRST OperationRegion into SSDT

[Laszlo Ersek]

On 12/23/13 17:24, Igor Mammedov wrote:
> On Mon, 23 Dec 2013 16:48:49 +0200
> "Michael S. Tsirkin" <address@hidden> wrote:
> 
>> On Mon, Dec 23, 2013 at 02:06:27PM +0100, Igor Mammedov wrote:
>>> On Mon, 23 Dec 2013 13:26:37 +0200
>>> "Michael S. Tsirkin" <address@hidden> wrote:

>>>> Interesting. This seems to imply that it can't access
>>>> IO port for the disk. Which boot disk type are you using?
>>>> Is the _CRS resource overlapping any other resource
>>>> by any chance?
>>> Yes, I've dug in the issue more and it is indeed _CRS overlapping with PCI 
>>> bus.
>>> PCI bus's IO ports are statically defined in acpi-dsdt-pci-crs.dsl and
>>> basically take all io ports except of 0xcf8-0xcff hole.
>>> Since PIIX4_PM and ICH9 LPC are PCI devices, it appears that PRST already
>>> covered by bus CRS, the same applies to PCI hotplug as well.
>>> So I was doing it wrong trying advertise bus resources out of bus scope.
>>
>> Yes, that's explicitly prohibited by the firmware specification.
>>
>>> What we need is to add PIIX4_PM/ICH9 LPC device definition with consumed IO
>>> ports CRS to PCI bus. Question is what PNP IDs they should use?
>>>
>>> It looks pretty much out of scope of cpu_hotplug and should be done for
>>> pci hotplug as well. So I'm ditching ACPI device and CRS parts from this
>>> series as not directly related.
>>> Adding PIIX4_PM/ICH9 LPC ACPI device could be done later and preferably
>>> for all resources consumed by it to make it right.
>>
>> Could be ok but are we using any new ports?
> yes, for q35. series adds 0xa18-0xa37 IO ports, it was requested by Gerd not
> to use 0xaf00-0xaf1f.
> 
>> If yes then I think before doing that we should make sure _CRS for
>> the host bridge does not include them, or consume them
> I'm fine with making holes in PCI bus CRES template, I can do it for
> pci-hotplug as well while at it.

Can you guys please summarize the problem? (Just so I can understand.)

\_SB.PCI0 consumes 0x0CF8..0x0CFF, and is a resource producer for all
other IO ports (ie. it passes them on to child devices). Did we try to
consume such a passed-on port in a device that is *not* a child of
\_SB.PCI0?

And if so, what's the suggested solution? Make the new consumer a child
of \_SB.PCI0, or punch out the new (non-child) consumer's port range
from \_SB.PCI0's forwarding?

>> in some child device.
> that would be cleanest, but is there any suggestion what device(s) it would be
> for piix and ich9-lpc, i.e. which PNP IDs should we use?

You could browse
<http://www.plasma-online.de/english/identify/serial/pnp_id_pnp.html>.

One suggestion could be:

PNP0C02 -- General ID for reserving resources required by PnP
motherboard registers. (Not device specific.)

(AFAICS this PNP ID has been mentioned earlier in the thread.)

PNP0C08 -- ACPI system board hardware

(Also used already, apparently.)

Laszlo