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

[Tony Camuso <tcamuso@redhat.com>]

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.