From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vwhwt-0000lf-Aj for qemu-devel@nongnu.org; Fri, 27 Dec 2013 19:40:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vwhwo-0007HY-8S for qemu-devel@nongnu.org; Fri, 27 Dec 2013 19:40:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vwhwo-0007HA-0q for qemu-devel@nongnu.org; Fri, 27 Dec 2013 19:40:10 -0500 Date: Sat, 28 Dec 2013 01:39:50 +0100 From: Igor Mammedov Message-ID: <20131228013950.25d1c420@thinkpad> In-Reply-To: <52B86A33.1090306@redhat.com> 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> <52B86A33.1090306@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Laszlo Ersek 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 Mon, 23 Dec 2013 17:52:03 +0100 Laszlo Ersek wrote: > 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? 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 > . > > 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