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

From: Jeff Garzik
Date: Sat Dec 22 2007 - 20:27:25 EST


Linus Torvalds wrote:

On Sat, 22 Dec 2007, Arjan van de Ven wrote:

On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik <jeff@xxxxxxxxxx> wrote:
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.

That _really_ doesn't work.

Old machines don't go away. We can't just say "wait a year and turn on MMCONFIG", because all the broken machines WILL STILL EXIST.

You are reinforcing my point :)

The exact same thing can be said for PCI MSI machines that are broken. Outside of Intel machines, early PCI MSI life was yucky and broken. Time passed, we got a handle on the problem set, we quirked that problematic set of systems, and life moved on.

And these days, we are benefitting from that -- most new hardware is MSI-capable if not MSIX-capable, and we are turning that on.

Some day in the future MSI-only (no INTX) hardware will ship in volume, and we will already be adequately prepared for that day.

But here the two items diverge: PCI MSI _can_ be an _option_ for most hardware, hence pci_enable_msi(). But the same cannot be said for MMCONFIG, for reasons outlined below...


Do you hate the name or the concept? I'm certainly open for a better name....

Just make it so. The name is fine, the concept is unavoidable. The people who complain are whiners that haven't ever had to deal with the fact that there are broken machines around.

For example, right now Jeff never sees the problem, because when MMCONFIG doesn't work, it's never his problem - nothing in the machine works. But if he has to add a "pci_enable_mmconfig()" to the drivers he maintains, he sees it as a _new_ problem, so he obviously thinks it's stupid: he was never impacted by the issues it fixed!

I forcibly turn on mmconfig on all my machines, and monitor lkml, to make sure I'm aware of the extent of the problem -- and the extent of peoples' exaggeration of this problem.


So it's natural for Jeff to not like it, but that doesn't make Jeff right in this case. It just means that Jeff never had to worry about it before, because as long as MMCONFIG wasn't per-driver, the problems it caused were never *his* problems. But that doesn't make them less of a problem.

Doing it at the driver level fundamentally doesn't work:

Regardless of whether a driver is loaded or not, you may NEED to see extended capabilities. The system may NEED to see those capabilities just to parse them for sane operation.

And pciutils should be able to see all of config space, not just the Linus-sanitized portion of it. This will make debugging more difficult, for example, because "lspci -vvvxxx" will not be giving me the full "before" and "after" snapshots I need from users, to see if anything changes based on <some hardware poking during debugging>.

I know when you look you see all sorts of brokenness. But you and I both know that will pass, with time. If its buggy, turn it off. If not, turn it on. All these hardware makers are paying attention and fixing errata; evidence of forward progress in that regard has already appeared even.

Finally, this introduces a new per-device model for PCI config space accesses, something we have NEVER done before. PCI config space should always be all or none. If MMCONFIG is fucked, just turn it off completely.

Having to deal with NEW issues brought on by this NEW per-device config space access model is stupid-by-design. Always-off is better than changing the access model from global to per-device.

It is even MORE unlikely that hardware makers test the "mmconfig over here, type1 over there" mixed accesses. Linux should not go down that road.

Always-off is better than mixed access models.

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/