From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: imammedo@redhat.com, qemu-devel@nongnu.org,
Anthony Liguori <aliguori@amazon.com>
Subject: Re: [Qemu-devel] [PATCH v2] x86: gigabyte alignment for ram
Date: Mon, 20 Jan 2014 17:51:47 +0200 [thread overview]
Message-ID: <20140120155147.GA1806@redhat.com> (raw)
In-Reply-To: <1390232217.11527.56.camel@nilsson.home.kraxel.org>
On Mon, Jan 20, 2014 at 04:36:57PM +0100, Gerd Hoffmann wrote:
> > 4.1.2.
> > MCFG Table Description
> >
> >
> > ...
> >
> > If the operating system does not natively comprehend reserving the MMCFG
> > region, the MMCFG region must be reserved by firmware. The address range
> > reported in the MCFG table or by _CBA method (see Section 4.1.3) must be
> > 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’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
>
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.
next prev parent reply other threads:[~2014-01-20 15:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-16 9:11 [Qemu-devel] [PATCH v2] x86: gigabyte alignment for ram Gerd Hoffmann
2013-12-16 11:54 ` Michael S. Tsirkin
2013-12-16 13:46 ` Gerd Hoffmann
2013-12-16 19:28 ` Michael S. Tsirkin
2013-12-17 10:54 ` Gerd Hoffmann
2013-12-17 11:59 ` Michael S. Tsirkin
2013-12-17 17:56 ` Gerd Hoffmann
2013-12-18 10:05 ` Michael S. Tsirkin
2014-01-20 11:23 ` Michael S. Tsirkin
2014-01-20 12:58 ` Gerd Hoffmann
2014-01-20 13:59 ` Michael S. Tsirkin
2014-01-20 14:01 ` Gerd Hoffmann
2014-01-20 14:22 ` Michael S. Tsirkin
2014-01-20 15:36 ` Gerd Hoffmann
2014-01-20 15:51 ` Michael S. Tsirkin [this message]
2014-01-20 17:15 ` Igor Mammedov
2014-01-21 7:27 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140120155147.GA1806@redhat.com \
--to=mst@redhat.com \
--cc=aliguori@amazon.com \
--cc=imammedo@redhat.com \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.