All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rajesh Shah <rajesh.shah@intel.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Brice Goglin <brice@myri.com>,
	LKML <linux-kernel@vger.kernel.org>, Andi Kleen <ak@suse.de>
Subject: Re: [RFC] PCI extended conf space when MMCONFIG disabled because of e820
Date: Wed, 21 Jun 2006 15:19:43 -0700	[thread overview]
Message-ID: <20060621151942.A17228@unix-os.sc.intel.com> (raw)
In-Reply-To: <4491029D.4060002@linux.intel.com>; from arjan@linux.intel.com on Wed, Jun 14, 2006 at 11:47:57PM -0700

On Wed, Jun 14, 2006 at 11:47:57PM -0700, Arjan van de Ven wrote:
> 
> > We need to improve this "mmconfig disabled" anyhow. Having the extended
> > config space unavailable on lots of machines is also far from a viable
> > solution :)
> 
> it's unlikely to be many machines though.
> 
I just noticed today - this check killed PCI Express on 3 of the 4
machines I normally use for testing. Digging a bit deeper, I found
this in the PCI firmware spec (v 3.0):

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.
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. The resources can optionally be returned in
Int15 E820 or EFIGetMemoryMap as reserved memory but must always be
reported through ACPI as a motherboard resource

Sure enough, the ACPI namespace for the "broken" machines lists
the MMCFG resources as indicated above, and PCI Express works fine
otherwise. I haven't looked yet whether it's possible to add this
check in the code, have you looked into that option? I understand
the PCI firmware spec is not necessarily the final authority on
this, but a _lot_ of BIOS developers read that to figure out what
to do...

Rajesh

  reply	other threads:[~2006-06-21 22:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-14 21:07 [RFC] PCI extended conf space when MMCONFIG disabled because of e820 Brice Goglin
2006-06-14 21:09 ` Arjan van de Ven
2006-06-15  1:45   ` Andi Kleen
2006-06-15  1:57   ` Brice Goglin
2006-06-15  6:47     ` Arjan van de Ven
2006-06-21 22:19       ` Rajesh Shah [this message]
2006-06-21 22:32         ` Andi Kleen
2006-06-22  0:15           ` Rajesh Shah
2006-06-22  9:27             ` Arjan van de Ven
2006-06-23  7:41               ` Rajesh Shah
  -- strict thread matches above, loose matches on Subject: below --
2006-06-15  8:41 Chuck Ebbert
2006-06-15 13:18 ` Arjan van de Ven
2006-06-15 14:32   ` Barry Scott

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=20060621151942.A17228@unix-os.sc.intel.com \
    --to=rajesh.shah@intel.com \
    --cc=ak@suse.de \
    --cc=arjan@linux.intel.com \
    --cc=brice@myri.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 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.