From: Arjan van de Ven <arjan@linux.intel.com>
To: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Konrad Rzeszutek <konradr@us.ibm.com>,
linux-kernel@vger.kernel.org, konradr@redhat.com
Subject: Re: [patch] Ignore MCFG if the mmconfig area isn't reserved in the e820 table.
Date: Thu, 18 May 2006 11:15:32 -0700 [thread overview]
Message-ID: <446CB9C4.6060606@linux.intel.com> (raw)
In-Reply-To: <446CB791.5030304@vc.cvut.cz>
Petr Vandrovec wrote:
> Arjan van de Ven wrote:
>> Konrad Rzeszutek wrote:
>>
>>> That is definitely a problem - and the "sanity-check" can definitly bail
>>> out on those BIOSes and not crash Linux. The other side of the coin
>>> is that BIOSes that do implement the MCFG/E820 correctly are penalized:
>>
>> I hereby contest that it's implemented correctly if it's not marked
>> reserved...
>
> PCI Firmware Specification 3.0
> (http://www.pcisig.com/members/downloads/specifications/conventional/pcifw_r3.0.pdf),
> page 42, notes for table 4-2, paragraph 2 says that firmware must report
> MCFG as reserved region. Last sentence of same paragraph says that
> resources may be optionally marked reserved by E820 or EFIGetMemoryMap,
resources == BARs, MCFG is a whole different beast
> but must be always reported as motherboard resources through ACPI (for
> exact citation please see document itself, it is not freely available so
> I'm not going to copy-paste text from it without written permission from
> pcisig...).
>
> So it seems to me that BIOS not reporting MMCONFIG as reserved through
> E820 is compliant, and what matters is that MMCONFIG must be reported as
> ACPI motherboard resource.
I think that's not the right interpretation; resources==BARs in this context.
I'll find a way to get that document and recheck to make sure...
next prev parent reply other threads:[~2006-05-18 18:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-18 2:53 [patch] Ignore MCFG if the mmconfig area isn't reserved in the e820 table Konrad Rzeszutek
2006-05-18 13:03 ` Arjan van de Ven
2006-05-18 15:56 ` Konrad Rzeszutek
2006-05-18 16:46 ` Arjan van de Ven
2006-05-18 18:06 ` Petr Vandrovec
2006-05-18 18:15 ` Arjan van de Ven [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-03-23 18:22 Arjan van de Ven
2006-03-23 17:56 ` Andi Kleen
2006-03-23 19:02 ` Arjan van de Ven
2006-03-23 19:15 ` Arjan van de Ven
2006-03-24 12:19 ` Andi Kleen
2006-03-24 13:36 ` Arjan van de Ven
2006-03-24 21:25 ` Greg KH
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=446CB9C4.6060606@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=konradr@redhat.com \
--cc=konradr@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vandrove@vc.cvut.cz \
/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.