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

[Loic Prylli]

On 12/22/2007 11:52 PM, Jeff Garzik wrote:
>
> Absolutely.
>
> But regardless of problems, enabling should be done globally, not per
> device...  




The "enabling globally" requirement, i.e. not per-device, neither
depending on reg >= 256 seems a very debatable assumption (IMHO a big
mistake) that seems to be responsible for many of the problems seen in
the past.



There might be for a very long time AMD-architectures where
extended-conf-space access for pci-express device works and is
beneficial (and where mmconf is not supported by the hardware on
non-pci-express devices). You are basically saying you don't want ever
to support extended-conf-space globally for those systems, where it
would be so easy to precisely use mmconf *only* when attempting
*extended-conf-space * (>= 256) to some device  (that provides a strong
guarantee that you will never break anything unless somebody actually
tries to use the extended-conf-space).


Supporting extended-conf-space is independant of the issue of using
mmconf for legacy conf-space. There is no real reason to use the same
method to access both. I have seen several arguments used that were
implying that, and they all seem really bogus to me. Not only are the
two ranges (<= 256 and >= 256) structurally independant (you have
totally independant capabilities lists that are independantly organized
in each of them), even if they were not there is no consistency issue
that cannot be dealt with a memory barrier, and the concern about taking
an extra branch for each pci-conf-space access is also bogus once you
look at the numbers.


By possibly using different implementations for the two ranges you avoid
introducing a new API, you avoid taking risks with mmconf when you don't
need it. That doesn't preclude using mmconf for everything either if the
user requests it or based on enough knowledge of the system to be sure
nothing will break.



Loic

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