Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIGis used

From: Yinghai Lu
Date: Thu Sep 13 2007 - 16:05:44 EST


Andreas Herrmann wrote:
On Thu, Sep 13, 2007 at 01:53:15PM +0200, Andi Kleen wrote:
On Thursday 13 September 2007 12:47, Greg KH wrote:
On Thu, Sep 13, 2007 at 11:47:42AM +0200, Andi Kleen wrote:
On Thursday 13 September 2007 04:21, Yinghai Lu wrote:
[PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is
used.

reuse pci_cfg_space_size but skip check pci express and pci-x CAP ID.
I just rejected a similar patch -- this should be done using MMCONFIG
But what about for broken machines without the proper MMCONFIG entries?
They still need a way to get access to this config space,
If there are any devices that need it. IBS and PCI-E error handling do, but they're quite obscure.

Also so far we don't know of any Fam 10h systems without MMCONFIG
entries. Fam10h requires a new BIOS so it's reasonable to assume
that the new BIOSes will do better.

IMHO support for all config space access methods should be added to the kernel.
And it should be added at a central point. Not waiting for drivers to do it
their own way if they need to use it.

The more complicated/important question is how to decide which access method
should be used for a device. (Something similar to the pci_mmcfg_fallback_slots
stuff that exists already for K8 NB.)
But that needs some more thinking.

Here a summary wrt family 10h extended config space access methods.
(Most of this stuff I verified with some patched kernels. I didn't
eavesdropping on the physical links though ...)

For family 10h we have 3 methods
(1) "legacy" MMCONFIG access (via south bridge)
(2) mmconfig access via CPU/NB (new with fam10h, using the new MMIO
config base MSR)
(3) CF8/CFC ECS access (new with fam10h, has to be enabled in the NB_CFG MSR)

ECS access in NB_CFG_MSR is always enabled. because BIOS need to use that to do mem initialization.

mmconfig enablement in BIOS is depending ....

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