From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5IS4-0008Vp-2x for qemu-devel@nongnu.org; Mon, 20 Jan 2014 12:16:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5IRz-00044m-D2 for qemu-devel@nongnu.org; Mon, 20 Jan 2014 12:15:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43923) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5IRy-00040J-JW for qemu-devel@nongnu.org; Mon, 20 Jan 2014 12:15:51 -0500 Date: Mon, 20 Jan 2014 18:15:46 +0100 From: Igor Mammedov Message-ID: <20140120181546.33eff8c0@nial.usersys.redhat.com> In-Reply-To: <20140120155147.GA1806@redhat.com> References: <20131216192843.GB21330@redhat.com> <1387277686.12500.35.camel@nilsson.home.kraxel.org> <20131217115936.GA30168@redhat.com> <1387302966.12500.85.camel@nilsson.home.kraxel.org> <20140120112345.GA11565@redhat.com> <1390222725.11527.46.camel@nilsson.home.kraxel.org> <20140120135907.GB31950@redhat.com> <1390226510.11527.49.camel@nilsson.home.kraxel.org> <20140120142227.GA1017@redhat.com> <1390232217.11527.56.camel@nilsson.home.kraxel.org> <20140120155147.GA1806@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2] x86: gigabyte alignment for ram List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Gerd Hoffmann , Anthony Liguori , qemu-devel@nongnu.org On Mon, 20 Jan 2014 17:51:47 +0200 "Michael S. Tsirkin" wrote: > On Mon, Jan 20, 2014 at 04:36:57PM +0100, Gerd Hoffmann wrote: > > > 4.1.2. > > > MCFG Table Description > > >=20 > > >=20 > > > ... > > >=20 > > > If the operating system does not natively comprehend reserving the MM= CFG > > > region, the MMCFG region must be reserved by firmware. The address ra= nge > > > reported in the MCFG table or by _CBA method (see Section 4.1.3) must= be > > > reserved by declaring a motherboard resource. > >=20 > > We don't do this today. > >=20 > > > For most systems, the > > > motherboard resource would appear at the root of the ACPI namespace > > > (under \_SB) in a node with a _HID of EISAID (PNP0C02), and the > > > resources in this case should not be claimed in the root PCI bus=E2= =80=99s _CRS. > >=20 > > Which I read as _in case it is at the root of the apci namespace_ it > > should not be claimed in PCI0._CRS. Which makes sense. > >=20 > > My laptop has it reserved in a \_SB\PCI0\LPC\SIO device instead: > >=20 > > Device (LPC) > > { > > Name (_ADR, 0x001F0000) // _ADR: Address > > Name (_S3D, 0x03) // _S3D: S3 Device State > > Name (RID, 0x00) > > Device (SIO) > > { > > Name (_HID, EisaId ("PNP0C0P2")) > > Name (_UID, 0x00) // _UID: Unique ID > > Name (SCRS, ResourceTemplate () > > { > > [ ... ] > > Memory32Fixed (ReadWrite, > > 0xF8000000, // Address Base > > 0x04000000, // Address Length > > ) > > [ ... ] > >=20 > > cheers, > > Gerd > >=20 >=20 > We can try, but Igor tried to do something like this recently ( > for IO resources) and windows guests kept crashing > unless he made holes in _CRS. I've tried to consume ranges under piix_pm/lpc device, there were no any indication that ranges were ever consumed. I haven't tried to put PNP0C0P2 on PCI bus though. It might work I just found similar code in coreboot https://www.mail-archive.com/coreboot@coreboot.org/msg27723.html