From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:47476)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1W5H4E-0006h8-Mu
	for qemu-devel@nongnu.org; Mon, 20 Jan 2014 10:47:20 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1W5H45-0001cA-7y
	for qemu-devel@nongnu.org; Mon, 20 Jan 2014 10:47:14 -0500
Received: from mx1.redhat.com ([209.132.183.28]:18272)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1W5H44-0001c0-Vd
	for qemu-devel@nongnu.org; Mon, 20 Jan 2014 10:47:05 -0500
Date: Mon, 20 Jan 2014 17:51:47 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1390232217.11527.56.camel@nilsson.home.kraxel.org>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH v2] x86: gigabyte alignment for ram
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: imammedo@redhat.com, qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>

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 ("PNP0C02"))
>                     Name (_UID, 0x00)  // _UID: Unique ID
>                     Name (SCRS, ResourceTemplate ()
>                     {
>                         [ ... ]
>                         Memory32Fixed (ReadWrite,
>                             0xF8000000,         // Address Base
>                             0x04000000,         // Address Length
>                             )
>                         [ ... ]
>=20
> cheers,
>   Gerd
>=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.