To: Linus Torvalds <torvalds@...>, Arjan van de Ven <arjan@...>
Cc: Tony Camuso <tcamuso@...>, Matthew Wilcox <matthew@...>, Greg KH <greg@...>, Adrian Bunk <bunk@...>, Benjamin Herrenschmidt <benh@...>, Ivan Kokshaysky <ink@...>, Greg KH <gregkh@...>, <linux-kernel@...>, Jeff Garzik <jeff@...>, <linux-pci@...>, Martin Mares <mj@...>
But is there a ACPI-compliant/architecture that only offers mmconfig for
configuration-space access and no other fallback method (i.e. no conf1,
no bios,...)?
2.6.24 supports mmconfig for:
- ACPI-system with MCFG
- a couple chipset discovered by conf1
If a system has no conf1, but does not have e820+ACPI+MCFG, or does have
some other method than mmconfig, it was already irrelevant in the
discussion of Ivan's initial patch in december (because that system was
either never supported or not impacted, and we were trying to fix bugs,
not introduce support for new class of systems).
Maybe Arjan could share his knowledge, and tell us what system he was
thinking about (and whether it needed to be supported by 2.6.24) when
saying:
"When (and I'm saying "when" not "if") systems arrive that only have
MMCONFIG for some of the devices."
Anyway Ivan's patch + Matthew's extensions are handling that non-PC
arch. That combination is advocated by at least:
Ivan Kokshaysky
Matthew Wilcox
Tony Camuso
Loic Prylli
even Arjan's said that while he prefers his patch (saying it's more
conservative), he does not see a existing problem with the Ivan/Matthew
combination.
[ simpler, less ambitious fixes can be forgotten if nothing can be done
for 2.6.24, I can understand that choice ]
The list of problems I see with Arjan's patch are:
- no word on whether the existing Linux driver/pci/pcie/aer code should
be converted to opt-in?
- mmconfig still needs to be revisited to sort-out the mix of
mmconfig+conf1+third-method access.
- you cannot test if ext-conf-space is available without taking risks:
when pci_enable_ext_config() is called, even legacy-conf-space is
switched to the new method. So some administrator action (lspci -v
+maybe-other-flag) or some driver action (that can optionally use
ext-conf-space but does not *rely* on it) could cause some devices to
totally disappear (if some pci hierarchy is handled by mmconfig as a
0xffffffff section as seen on many amd machines). Matthew/Ivan will
simply in the worst case detect that ext-conf-space is not available in
pci_cfg_space_size()), legacy-conf-space will still work (and that
0xffffffff section is perfectly *safe* to query, tell me if you need
more details of why).
- introduce a new user-api, and a new kernel API, while in practice
there is no evidence that brings any benefits compared to Ivan/Matthew.
IMHO, making "pci=nommconf" the default behaviour is better than
Arjan's patch: for the exaggerated 99.99% users he claims don't need
ext-conf-space, that's obviously as good. And many of the others would
benefit from the ability to test and optionally use ext-conf-space is
available without taking the risk of crashing something, so something
else is better for them.
With Arjan's patch, in 10 years, we might still have to use an extra
option (or some other action) when using lspci to display extended caps,
and we would still run the risk of crashing some old machine when doing
so (unless maybe a blacklist of some sort will be added, making the
newly introduced API completely useless soon, or unless we keep the
painful bitmaps in mmconfig potentially ending-up with 3 set of pci-ops).
Loic
--
