From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:44729)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1W5GuT-00012b-8F
	for qemu-devel@nongnu.org; Mon, 20 Jan 2014 10:37:18 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1W5GuN-0006pd-8M
	for qemu-devel@nongnu.org; Mon, 20 Jan 2014 10:37:09 -0500
Received: from mx1.redhat.com ([209.132.183.28]:3973)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1W5GuM-0006pP-Vc
	for qemu-devel@nongnu.org; Mon, 20 Jan 2014 10:37:03 -0500
Message-ID: <1390232217.11527.56.camel@nilsson.home.kraxel.org>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Mon, 20 Jan 2014 16:36:57 +0100
In-Reply-To: <20140120142227.GA1017@redhat.com>
References: <20131216115401.GA19233@redhat.com>
	<1387201577.28883.38.camel@nilsson.home.kraxel.org>
	<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>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
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: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>

> 4.1.2.
>  MCFG Table Description
>=20
>=20
> ...
>=20
> If the operating system does not natively comprehend reserving the MMCF=
G
> region, the MMCFG region must be reserved by firmware. The address rang=
e
> reported in the MCFG table or by _CBA method (see Section 4.1.3) must b=
e
> reserved by declaring a motherboard resource.

We don't do this today.

> 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=99=
s _CRS.

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.

My laptop has it reserved in a \_SB\PCI0\LPC\SIO device instead:

            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
                            )
                        [ ... ]

cheers,
  Gerd