public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@linux.intel.com>
To: Konrad Rzeszutek <konradr@us.ibm.com>
Cc: 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 09:46:11 -0700	[thread overview]
Message-ID: <446CA4D3.80105@linux.intel.com> (raw)
In-Reply-To: <20060518155642.GC7617@andromeda.dapyr.net>

Konrad Rzeszutek wrote:
>>> Also the ACPI spec v3.0 (pg 405 of PDF, section 14.2, titled:
>>> "E820 Assumptions and Limitations") agrees with this:
>>>
>>> "The BIOS does not return a range description for the memory mapping
>>> of PCI devices, ISA Option ROMs, and the ISA PNP cards because the OS
>>> has mechanisms available to detect them."
>> MCFG is none of these...
> 
> This is a bit of gray area. 

How? The segment you quoted basically says "no need to put any "MEM" resources
into E820 because the OS will know about those from its PCI scan".
And for an OS to map pci devices like cardbus or hotplug PCI anywhere, it obviously
needs to know about PCI so this is entirely a fair assumption.

MCFG is new. It's not traditional and it generally isn't a MEM region on any
PCI device. The result is that OSes that do not know about MCFG (like Windows XP)
do not at all know that there is something there already in the address space.
Neither the wording of the spec pieces you quoted nor common sense can lead to
a "but it doesn't have to be marked reserved" interpretation... the OS just has
to know what address space is free for mapping things into, via one way or another.


> If the MMCONFIG falls in that assumed memory mapped 256MB - then 
> the quote from section 14.2 can apply to that particular situation 
> "The BIOS does not return a range for the memory mapping of PCI devices ...";

yes this is the MEM BARs. Different animal.

> 
>>> If this is not a specification issue, I was wondering if perhaps for the 
>>> machines you refer to, their BIOS bug is that the E820 have memory ranges
>>> which also encompass what MMCONF points to?
>> no their bug is mostly that MCFG is garbage in those bioses. It points 
>> plain to
>> the wrong place. They even reserved the correct range, just pointed mcfg at 
>> the
>> wrong place.
>>
> 
> 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...

> the 
> MMCONFIG capability on those machines is turned off when using Linux
> 2.6.17. 
> 
> Could you provide more details on the BIOS? Did the vendor released an updated BIOS? 

there were several, some I can't talk about.
Let me ask you a counter question: could you provide more details on the opposite case, and did the
vendor release an updated, fixed BIOS ?


  reply	other threads:[~2006-05-18 16:46 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 [this message]
2006-05-18 18:06       ` Petr Vandrovec
2006-05-18 18:15         ` Arjan van de Ven
  -- 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=446CA4D3.80105@linux.intel.com \
    --to=arjan@linux.intel.com \
    --cc=konradr@redhat.com \
    --cc=konradr@us.ibm.com \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox