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

[Ivan Kokshaysky <ink@jurassic.park.msu.ru>]

On Sun, Dec 23, 2007 at 12:44:30AM -0500, Jeff Garzik wrote:
> Failures are more predictable and more consistent with an all-or-none 
> scenario.  The all-or-none solutions are the least complex on the software 
> side, and far more widely tested than any mixed config access scheme.

Nope. The vast majority of mmconfig problems that happen at boot time
actually have nothing to do with "broken" or "working" mmconfig.
Typically these are
- mmconf area overlapped during BAR sizing;
- BIOS (or kernel) placed some MMIO in the middle of mmconfig area,
  which looks like some random device "doesn't like mmconfig".

This is a result of all-or-none approach, as mmconfig is fundamentally
unsafe until after PCI init is done.

The mixed access that Loic proposes allows to avoid these boot problems
just for free. Systems that have both non-mmconf PCI(X) and mmconf PCI-E
domains could be handled almost for free as well.
And probably most important thing is that the x86 pci_conf implementation
would be so much simpler and cleaner that I honestly don't understand
why are we still discussing it ;-)

At the same time, making drivers to request extended config space
still makes sense. I think of pci_request_ext_conf(dev, drv_name) which
doesn't set any per-device flag, but
- returns success or failure depending on mmconf availability;
- can be logged by kernel to make it easier to debug if something
  goes wrong.

Ivan.