Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On Thu, Sep 13, 2007 at 10:20:56AM -0700, H. Peter Anvin wrote: > Yinghai Lu wrote: > > > > BIOS guys also said that fam 10h need mmconfig via eax accessing, may > > need OS do sth, so it is safe to stay with MCFG entry for SB like > > mcp55... > > > > but latest kernel already have that workaround to make mmconfig via eax... > > > > This is actually a good point. Since the CPU vendor managed to > completely fuck up the operation of MMCONFIG itself on this CPU (it's a > *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent It's quite possible that Windows MCFG code always ends up using EAX. In fact many older Linux kernels ended up doing this by chance too. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On Thu, Sep 13, 2007 at 10:20:56AM -0700, H. Peter Anvin wrote: Yinghai Lu wrote: BIOS guys also said that fam 10h need mmconfig via eax accessing, may need OS do sth, so it is safe to stay with MCFG entry for SB like mcp55... but latest kernel already have that workaround to make mmconfig via eax... This is actually a good point. Since the CPU vendor managed to completely fuck up the operation of MMCONFIG itself on this CPU (it's a *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent It's quite possible that Windows MCFG code always ends up using EAX. In fact many older Linux kernels ended up doing this by chance too. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
Andreas Herrmann wrote: > On Thu, Sep 13, 2007 at 10:20:56AM -0700, H. Peter Anvin wrote: >> Yinghai Lu wrote: >>> BIOS guys also said that fam 10h need mmconfig via eax accessing, may >>> need OS do sth, so it is safe to stay with MCFG entry for SB like >>> mcp55... >>> >>> but latest kernel already have that workaround to make mmconfig via eax... >>> >> This is actually a good point. Since the CPU vendor managed to >> completely fuck up the operation of MMCONFIG itself on this CPU (it's a >> *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent >> that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually >> work on this CPU for any system software which doesn't already know to >> work around this particular piece of severe braindamage; > > But wait, isn't it true that Vista is using MCFG? > So, poor BIOS guys what should they do now? > If you have a special problem here why not upgrading your Linux kernel? > I'm not talking about Linux here. I'm talking about any random system software (which may or may not be Vista, and may nor may not even be an OS.) If they advertise MCFG, then a random OS could try to use it, in accordance with the spec, without the workaround, with serious malfunction as a result. If they don't include MCFG, then the worst thing that can happen is that the OS doesn't see the extended space. An OS that has chip-specific workarounds can be aware that this chip is Special and enable MMCONFIG and use it anyway. In RFC-speak: Since this chip doesn't implement standards-conformant mmconfig, a BIOS MUST NOT enable MCFG in ACPI. As a result, OSes that have chip-specific workarounds, like Linux has, SHOULD detect it and use ad hoc code to enable it anyway. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On Thu, Sep 13, 2007 at 10:20:56AM -0700, H. Peter Anvin wrote: > Yinghai Lu wrote: > > > > BIOS guys also said that fam 10h need mmconfig via eax accessing, may > > need OS do sth, so it is safe to stay with MCFG entry for SB like > > mcp55... > > > > but latest kernel already have that workaround to make mmconfig via eax... > > > > This is actually a good point. Since the CPU vendor managed to > completely fuck up the operation of MMCONFIG itself on this CPU (it's a > *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent > that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually > work on this CPU for any system software which doesn't already know to > work around this particular piece of severe braindamage; But wait, isn't it true that Vista is using MCFG? So, poor BIOS guys what should they do now? If you have a special problem here why not upgrading your Linux kernel? > standards-complicant MMCONFIG isn't supported at all. And yes, it is complicated to follow your argumentation. Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
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) - If (1) is used and (2)+(3) are not configurred there is no way to access NB config space with mmconfig accesses. Which implies that NB ECS cannot be accessed. So you can only access NB standard config space via "legacy" CF8/CFC. This equals what we have with K8. => ECS is accessible just for external devices (not the NB ECS). - If (2) is used, mmconfig accesses are translated by CPU/NB. So this will result in (extended) config cycles on the link to the south bridge. This works for both NB config space and config space for normal PCI(e) devices. => ECS is accessible for all devices via that method. - And finally with (3) you can also access both NB config space and the config space of external devices. The CPU/NB does the translation and will also create (extended) config cycles here. => ECS is accessible for all devices via that method. (But of course not in the same "atomic" manner like with mmconfig.) Then we have different prereqs for those methods: - For (1) the ACPI stuff is required. - For (2) and (3) some MSRs have to be set up. Ah, yes in case I didn't mention that: ;-) Using (2) you haven't such a strict dependency on that ACPI stuff. Would be cool to disable MCFG at all and configure mmconfig just in the CPU, no? Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
Yinghai Lu wrote: > On 9/13/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: >> Yinghai Lu wrote: >>> BIOS guys also said that fam 10h need mmconfig via eax accessing, may >>> need OS do sth, so it is safe to stay with MCFG entry for SB like >>> mcp55... >>> >>> but latest kernel already have that workaround to make mmconfig via eax... >>> >> This is actually a good point. Since the CPU vendor managed to >> completely fuck up the operation of MMCONFIG itself on this CPU (it's a >> *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent >> that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually >> work on this CPU for any system software which doesn't already know to >> work around this particular piece of severe braindamage; >> standards-complicant MMCONFIG isn't supported at all. > > if other mmconfig device on x86 is sick of accessing via eax, may need > to provide one fam10h_pci_mmcfg to be assigned to raw_pci_ops instead > and leave pci_mmcfg to default behavior ( *MEMORY REFERENCE*). > We already have the workaround. WE do. However, you could easily see why a BIOS vendor would want to leave out the MCFG ACPI info, since fam 10h's mmconfig is broken. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On 9/13/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Yinghai Lu wrote: > > > > BIOS guys also said that fam 10h need mmconfig via eax accessing, may > > need OS do sth, so it is safe to stay with MCFG entry for SB like > > mcp55... > > > > but latest kernel already have that workaround to make mmconfig via eax... > > > > This is actually a good point. Since the CPU vendor managed to > completely fuck up the operation of MMCONFIG itself on this CPU (it's a > *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent > that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually > work on this CPU for any system software which doesn't already know to > work around this particular piece of severe braindamage; > standards-complicant MMCONFIG isn't supported at all. if other mmconfig device on x86 is sick of accessing via eax, may need to provide one fam10h_pci_mmcfg to be assigned to raw_pci_ops instead and leave pci_mmcfg to default behavior ( *MEMORY REFERENCE*). YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
Yinghai Lu wrote: > > BIOS guys also said that fam 10h need mmconfig via eax accessing, may > need OS do sth, so it is safe to stay with MCFG entry for SB like > mcp55... > > but latest kernel already have that workaround to make mmconfig via eax... > This is actually a good point. Since the CPU vendor managed to completely fuck up the operation of MMCONFIG itself on this CPU (it's a *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually work on this CPU for any system software which doesn't already know to work around this particular piece of severe braindamage; standards-complicant MMCONFIG isn't supported at all. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On 9/13/07, Andi Kleen <[EMAIL PROTECTED]> 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. BIOS guys also said that fam 10h need mmconfig via eax accessing, may need OS do sth, so it is safe to stay with MCFG entry for SB like mcp55... but latest kernel already have that workaround to make mmconfig via eax... YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
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. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
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, so why should we not also work properly for them? Until we can somehow flog all BIOS developers until they fix all of their bugs, we have to be able to handle things like this :( thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
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 -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
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 -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
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, so why should we not also work properly for them? Until we can somehow flog all BIOS developers until they fix all of their bugs, we have to be able to handle things like this :( thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
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. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On 9/13/07, Andi Kleen [EMAIL PROTECTED] 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. BIOS guys also said that fam 10h need mmconfig via eax accessing, may need OS do sth, so it is safe to stay with MCFG entry for SB like mcp55... but latest kernel already have that workaround to make mmconfig via eax... YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
Yinghai Lu wrote: BIOS guys also said that fam 10h need mmconfig via eax accessing, may need OS do sth, so it is safe to stay with MCFG entry for SB like mcp55... but latest kernel already have that workaround to make mmconfig via eax... This is actually a good point. Since the CPU vendor managed to completely fuck up the operation of MMCONFIG itself on this CPU (it's a *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually work on this CPU for any system software which doesn't already know to work around this particular piece of severe braindamage; standards-complicant MMCONFIG isn't supported at all. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On 9/13/07, H. Peter Anvin [EMAIL PROTECTED] wrote: Yinghai Lu wrote: BIOS guys also said that fam 10h need mmconfig via eax accessing, may need OS do sth, so it is safe to stay with MCFG entry for SB like mcp55... but latest kernel already have that workaround to make mmconfig via eax... This is actually a good point. Since the CPU vendor managed to completely fuck up the operation of MMCONFIG itself on this CPU (it's a *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually work on this CPU for any system software which doesn't already know to work around this particular piece of severe braindamage; standards-complicant MMCONFIG isn't supported at all. if other mmconfig device on x86 is sick of accessing via eax, may need to provide one fam10h_pci_mmcfg to be assigned to raw_pci_ops instead and leave pci_mmcfg to default behavior ( *MEMORY REFERENCE*). YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
Yinghai Lu wrote: On 9/13/07, H. Peter Anvin [EMAIL PROTECTED] wrote: Yinghai Lu wrote: BIOS guys also said that fam 10h need mmconfig via eax accessing, may need OS do sth, so it is safe to stay with MCFG entry for SB like mcp55... but latest kernel already have that workaround to make mmconfig via eax... This is actually a good point. Since the CPU vendor managed to completely fuck up the operation of MMCONFIG itself on this CPU (it's a *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually work on this CPU for any system software which doesn't already know to work around this particular piece of severe braindamage; standards-complicant MMCONFIG isn't supported at all. if other mmconfig device on x86 is sick of accessing via eax, may need to provide one fam10h_pci_mmcfg to be assigned to raw_pci_ops instead and leave pci_mmcfg to default behavior ( *MEMORY REFERENCE*). We already have the workaround. WE do. However, you could easily see why a BIOS vendor would want to leave out the MCFG ACPI info, since fam 10h's mmconfig is broken. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
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) - If (1) is used and (2)+(3) are not configurred there is no way to access NB config space with mmconfig accesses. Which implies that NB ECS cannot be accessed. So you can only access NB standard config space via legacy CF8/CFC. This equals what we have with K8. = ECS is accessible just for external devices (not the NB ECS). - If (2) is used, mmconfig accesses are translated by CPU/NB. So this will result in (extended) config cycles on the link to the south bridge. This works for both NB config space and config space for normal PCI(e) devices. = ECS is accessible for all devices via that method. - And finally with (3) you can also access both NB config space and the config space of external devices. The CPU/NB does the translation and will also create (extended) config cycles here. = ECS is accessible for all devices via that method. (But of course not in the same atomic manner like with mmconfig.) Then we have different prereqs for those methods: - For (1) the ACPI stuff is required. - For (2) and (3) some MSRs have to be set up. Ah, yes in case I didn't mention that: ;-) Using (2) you haven't such a strict dependency on that ACPI stuff. Would be cool to disable MCFG at all and configure mmconfig just in the CPU, no? Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On Thu, Sep 13, 2007 at 10:20:56AM -0700, H. Peter Anvin wrote: Yinghai Lu wrote: BIOS guys also said that fam 10h need mmconfig via eax accessing, may need OS do sth, so it is safe to stay with MCFG entry for SB like mcp55... but latest kernel already have that workaround to make mmconfig via eax... This is actually a good point. Since the CPU vendor managed to completely fuck up the operation of MMCONFIG itself on this CPU (it's a *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually work on this CPU for any system software which doesn't already know to work around this particular piece of severe braindamage; But wait, isn't it true that Vista is using MCFG? So, poor BIOS guys what should they do now? If you have a special problem here why not upgrading your Linux kernel? standards-complicant MMCONFIG isn't supported at all. And yes, it is complicated to follow your argumentation. Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
Andreas Herrmann wrote: On Thu, Sep 13, 2007 at 10:20:56AM -0700, H. Peter Anvin wrote: Yinghai Lu wrote: BIOS guys also said that fam 10h need mmconfig via eax accessing, may need OS do sth, so it is safe to stay with MCFG entry for SB like mcp55... but latest kernel already have that workaround to make mmconfig via eax... This is actually a good point. Since the CPU vendor managed to completely fuck up the operation of MMCONFIG itself on this CPU (it's a *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually work on this CPU for any system software which doesn't already know to work around this particular piece of severe braindamage; But wait, isn't it true that Vista is using MCFG? So, poor BIOS guys what should they do now? If you have a special problem here why not upgrading your Linux kernel? I'm not talking about Linux here. I'm talking about any random system software (which may or may not be Vista, and may nor may not even be an OS.) If they advertise MCFG, then a random OS could try to use it, in accordance with the spec, without the workaround, with serious malfunction as a result. If they don't include MCFG, then the worst thing that can happen is that the OS doesn't see the extended space. An OS that has chip-specific workarounds can be aware that this chip is Special and enable MMCONFIG and use it anyway. In RFC-speak: Since this chip doesn't implement standards-conformant mmconfig, a BIOS MUST NOT enable MCFG in ACPI. As a result, OSes that have chip-specific workarounds, like Linux has, SHOULD detect it and use ad hoc code to enable it anyway. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On Wed, 12 Sep 2007 19:21:43 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: > +/** > + * Regular PCI devices have 256 bytes, but AMD Family 10h Opteron ext config > + * have 4096 bytes. Even if the device is capable, that doesn't mean we can > + * access it. Maybe we don't have a way to generate extended config space > + * accesses. So check it > + */ Please don't use the kerneldoc leadin "/**" for non-kerneldoc comments. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On Wed, 12 Sep 2007 19:21:43 -0700 Yinghai Lu [EMAIL PROTECTED] wrote: +/** + * Regular PCI devices have 256 bytes, but AMD Family 10h Opteron ext config + * have 4096 bytes. Even if the device is capable, that doesn't mean we can + * access it. Maybe we don't have a way to generate extended config space + * accesses. So check it + */ Please don't use the kerneldoc leadin /** for non-kerneldoc comments. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
