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

[Jeff Garzik]

Arjan van de Ven wrote:
> On Sat, 22 Dec 2007 09:20:06 -0500
> Jeff Garzik <jeff@xxxxxxxxxx> wrote:
>
> > Arjan van de Ven wrote:
> > > Hi,
> > >
> > > Linus really wants the extended (4Kb) PCI configuration space
> > > (using MCFG acpi table etc) to be opt-in, since there's many issues
> > > with it and most drivers don't even use/need it. The idea behind
> > > opt-in is that if you don't use it, you don't get to suffer the
> > > bugs...
> > >
> > > Booted on my 64 bit test machine; sadly it has a defunct BIOS that
> > > doesn't have a working MCFG.
> > >
> > >
> > > From: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
> > > Subject: Make MMCONFIG space a driver opt-in
> > >
> > > There are many issues with using the extended PCI configuration
> > > space (CPU, Chipset and most of all BIOS bugs). This while the vast
> > > majority of drivers and devices don't even use/need to use the
> > > memory mapped access methods since they don't use the config space
> > > beyond the traditional 256 bytes.
> > >
> > > This patch makes accessing the extended config space a driver
> > > choice, via the
> > >
> > > pci_enable_ext_config(pdev)
> > Yuck.  And, Linus is just being silly.  Wait a year then turn on 
> > MMCONFIG :)  It took PCI MSI a while to mature, but is finally
> > getting there.
>
> Do you hate the name or the concept? I'm certainly open for a better name.... 

Many problems:

* even if driver not loaded, you might need to access extended capabilities

* kernel hacker (me!) might request user to dump PCI config space to see 
what changes, after various experiments.  we need to see that extended 
space, if it exists, even if driver not loaded.

* this "mixed config access" model is new to Linux, after always having 
config access type be a global system attribute.  It introduces new 
complexity and new inconsistency all over the place.

* hardware makers will not test this weird "mixed access" model.

You thought mmconfig was poorly tested?  Well, why the hell choose 
something with even less testing behind it (and future likelihood of nil 
testing).

Always-off is better than mixed access.

	Jeff


--
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/