From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vv8jp-0005wO-TC for qemu-devel@nongnu.org; Mon, 23 Dec 2013 11:52:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vv8jk-0006Zd-TH for qemu-devel@nongnu.org; Mon, 23 Dec 2013 11:52:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26286) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vv8jk-0006ZV-Lr for qemu-devel@nongnu.org; Mon, 23 Dec 2013 11:52:12 -0500 Message-ID: <52B86A33.1090306@redhat.com> Date: Mon, 23 Dec 2013 17:52:03 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1386951736-929-1-git-send-email-imammedo@redhat.com> <1386951736-929-10-git-send-email-imammedo@redhat.com> <20131216195307.GA23942@redhat.com> <20131222155128.6f76675d@thinkpad> <20131223112637.GA5619@redhat.com> <20131223140627.49ba07be@thinkpad> <20131223144849.GE21800@redhat.com> <20131223172430.5107c3de@thinkpad> In-Reply-To: <20131223172430.5107c3de@thinkpad> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 09/11] ACPI: move PRST OperationRegion into SSDT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: aliguori@amazon.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, hutao@cn.fujitsu.com, jjherne@us.ibm.com, brogers@suse.com, kraxel@redhat.com, stefanha@redhat.com, kaneshige.kenji@jp.fujitsu.com, chen.fan.fnst@cn.fujitsu.com, pbonzini@redhat.com On 12/23/13 17:24, Igor Mammedov wrote: > On Mon, 23 Dec 2013 16:48:49 +0200 > "Michael S. Tsirkin" 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" 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 . 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