On 12/23/13 17:24, Igor Mammedov wrote: > On Mon, 23 Dec 2013 16:48:49 +0200 > "Michael S. Tsirkin" <m...@redhat.com> 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" <m...@redhat.com> 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
