Cc: Ivan Kokshaysky <ink@...>, Greg KH <greg@...>, Matthew Wilcox <matthew@...>, Linus Torvalds <torvalds@...>, Greg KH <gregkh@...>, <linux-kernel@...>, Jeff Garzik <jeff@...>, <linux-pci@...>, Benjamin Herrenschmidt <benh@...>, Martin Mares <mj@...>, Tony Camuso <tcamuso@...>
> The point of my patch was to make people who don't need extended config space,
I think I got your point the first time, and I agree it is sound. But in
my subjective and biased opinion, I just think ext-conf-space is
already useful and widespread enough (being used is not the same as
being strictly required for basic operation) for your proposed tradeoff
to not be optimal (protecting against "future/non-proven" hardware bugs,
i.e. bringing non-proven benefits, at the expense of making life harder
for ext-conf-space users while bringing additional extra API/code).
To take an example from the linux tree: the driver/pci/pcie/aer code
uses ext-conf-space for every pcie-root (currently several distributions
enable it by default), does it mean opt-in would be automatically
activated for most pcie hierarchies (defeating most of the benefits of
being opt-in), or we just disable that code by default?
Does lspci -v will automatically opt-in all pcie (right now by default
it tries to list the extended-capabilities for pcie and pcix), or do we
now require manual explicit sysfs operations to get the whole thing? Is
is an additional flag to lspci (if so will that flag also apply to pcix,
possibly causing a crash for lspci -v
- on some machines).
> Note: There is not a 100% overlap between "need" and "will not be used in
To go one step your direction, I have already argued in a couple of
emails that I would prefer to not implement ext-conf-space access for
any PCI-X devices (removing PCI-X2 from pci_ext_cfg_size), because there
we are trying to support devices that we don't really know exists or
will ever exists. And protecting against "unproven bugs" makes more
sense when it only removes "unproven benefits".
>
FWIW, I have in my tree a patch almost identical to Ivan's dated
"December 2005". Because of the constant activity on the mmconfig front
(that I thought would make it obsolete), I never took the effort of
suggesting it before one month ago (I am not a regular user of
linux-kernel). I admit nobody else should view it that way, but for me
rather than the last attempt at fixing mmconfig, it's a patch first used
two years ago that would have arguably prevented all problems that have
been reported since then.
Besides, recent mails show that hypothetically, we could even not change
anything to the existing conf-space code, since the only known bug
remaining is the one associated with bar probing and could be adressed by:
[ Thanks to Robert hancok and Grant Grundler for explaining to me the
history of bar-probing last month ]
Even if that bar-probing patch was applied (maybe it needs to be more
combat-proven), by default, it still seems better to not use mmconfig
for legacy-conf-space access, but going two extra precaution steps
beyond what seems necessary might be excessive.
> Only time can tell I suppose, but the risk side is that
You can indeed never exclude 100% that possibility, but if they see a
problem again, it is likely to be a new category of hardware/BIOS bugs
never seen before.
