Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driveropt-in

[Tony Camuso]

To all ...

Well, here is what I perceive we've got so far.

. Some PCI Northbridges do not work with MMCONFIG.

. Some PCI BARs can overlap the MMCONFIG area during bus sizing.
  It is hoped that new BIOSes will locate MMCONFIG in an area
  safely out of the way of bus sizing code, but there can be
  no guarantees.

. conf1 is going away in newer x86 implementations in the not
  too distant future.

. The PCI express spec requires platforms to provide access to
  the extended config area, and there are express devices today
  using that area for AER.

. There is no need to provide different PCI config access
  mechanisms at device granularity, since the PCI config access
  mechanism between the CPU and the Northbridge is opaque to
  the devices. PCI config mechanisms only need to differ at
  the Northbridge level.

. We have a flurry of patches all claiming to solve all or some
  of these problems.


Arjan,

I realize it may not be possible for you to answer this question,
but I feel compelled to ask it anyway. Is it possible that future
x86 architectures will be implementing a SAL-like interface to
abstract PCI config access altogether?

Or can we condense these patches down to a set that does the
following?

. If the system is capable of conf1, then PCI config access
  at offsets < 256 should be confined to conf1. This solution
  is most effective for existing and legacy systems.

. If the system does not support MMCONFIG, of if MMCONFIG is
  not working, then accesses to offsets > 256 return -1 and an
  error status.

. For systems, where the conf1 mechanism is NOT available,
  then MMCONFIG should be the PCI access mechanism for all
  offsets. For such systems, we must assume that the BIOS has
  become smart enough to locate MMCONFIG in a region safe from
  encroachment by bus sizing code.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/