On 1/13/2008 3:43 PM, Matthew Wilcox wrote:

quoted text
> On Sun, Jan 13, 2008 at 10:41:24AM -0800, Arjan van de Ven wrote:

>

>> Note: There is not a 100% overlap between "need" and "will not be used in

>> the patches that use legacy for < 256". In the other patches posted,

>> extended config space will be used in cases where it won't be with my

>> patch. (Most obvious one is an "lspci -vx" from automated scripts).

>>

>

> I believe you to be mistaken in this belief.  If you take Ivan's patch,

> conf1 is used for all accesses below 256 bytes.  lspci -x only dumps

> config space up to 64 bytes; lspci -xxxx is needed to show extended pci

> config space.

>   

I agree with Arjan about that "not a 100% overlap". It is about the

extra ext-conf-space access done while probing in drivers/pci/probe.c:

    dev->cfg_size = pci_cfg_space_size(dev);
(and lspci -v will also query/show the list of extended-caps for

pci-x/pcie-x devices that have some, provided the kernel can access

ext-conf-space).
With Ivan's patch, that line would still cause one extended-conf-space

access at offset 256 for pcie/pci-x2 devices  (to check the ability to

query ext-space). Arjan "opt-in" patch would prevent that extra access.
IMHO that access is OK and harmless in all cases, we are already

protected by MCFG/e820 checks, but I agree one can express a different

opinion based on trying to prevent "never-seen/potential" hardware/BIOS

bugs. FWIW it is also there that I was suggested to exclude PCI-X2

devices (when restricted to pcie, that access while probing cannot even

cause the harmless master-abort/0xffffffff), but there is a small trade-off.
Loic
--

unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/