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

[Igor Mammedov]

On Mon, 23 Dec 2013 17:52:03 +0100
Laszlo Ersek <address@hidden> wrote:

> 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?
yep, and that was an error.

> 
> 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?
I've tried to add bridge that uses hotplug ports as Device under PCI bus with
respective _CRS so it would consume ports, unfortunately for PIIX bridge
isn't visible under Windows and any other ways to confirm that _CRS was
consumed failed. The same for linux. For Q35, Windows' device manager shows
LPC bridge however there is no "Resources" tab with consumed ports.
Due to lack of ways to confirm that _CRS was really consumed,
I've switched to punching holes, and exposing hotplug IO region as
\_SB.Device(ACPI0004)._CRS. It works rather stable with new and old
versions Windows.

> 
> >> 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.)
I've chosen ACPI0004 instead, as the later we might wish to group
CPU devices under it (when extending support for 1024 and more CPUs)

> 
> (AFAICS this PNP ID has been mentioned earlier in the thread.)
> 
> PNP0C08 -- ACPI system board hardware
it doesn't work.

> 
> (Also used already, apparently.)
> 
> Laszlo


-- 
Regards,
  Igor