Re: [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

Re: [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Andi Kleen]

On Thursday 30 August 2007 19:43:14 Robert Richter wrote:
> This patch implements PCI extended configuration space access for
> AMD's Barcelona CPUs. It extends the method using CF8/CFC IO
> addresses. An x86 capability bit has been introduced that is set for
> CPUs supporting PCI extended config space accesses.

We shouldn't need this because extended config space should work
here and Linux should use it 
(especially after we added the ugly Barcelona workaround into  that code) 

The only exception would be if the user disables MMCONFIG in CONFIG, but that's
their own fault then.

Ok there might be buggy BIOS around with no or no usable MCFG table, but since
extended config space is not really a critical feature that's not a big issue.

So I don't think we want this special case code at all and should
just rely on MMCONFIG.

-Andi

Re: [patch 1/5] x86: Add AMD64 Barcelona PMU MSR definitions

[Andi Kleen]

On Thursday 30 August 2007 19:43:12 Robert Richter wrote:
> Already added to the -mm tree.  Its filename is
>      i386-add-amd64-barcelona-pmu-msr-definitions.patch


Patch doesn't apply to -rc5 + ff tree.

Hunk #1 FAILED at 73.
Hunk #2 FAILED at 107.
2 out of 2 hunks FAILED -- rejects in file include/asm-i386/msr-index.h

If you want to do random white space changes and
code movement please do it in a separate patch in the future.

-Andi

Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Andreas Herrmann]

On Sat, Sep 01, 2007 at 12:11:52PM +0200, Andi Kleen wrote:
> On Thursday 30 August 2007 19:43:14 Robert Richter wrote:
> > This patch implements PCI extended configuration space access for
> > AMD's Barcelona CPUs. It extends the method using CF8/CFC IO
> > addresses. An x86 capability bit has been introduced that is set for
> > CPUs supporting PCI extended config space accesses.
> 
> We shouldn't need this because extended config space should work
> here and Linux should use it 
> (especially after we added the ugly Barcelona workaround into  that code) 

This patch is needed for all buggy BIOSes that don't correctly set up MCFG.

> The only exception would be if the user disables MMCONFIG in CONFIG, but that's
> their own fault then.

No, as you stated yourself there are two exceptions. And the more serious one is the
BIOS issue.

> Ok there might be buggy BIOS around with no or no usable MCFG table, but since
> extended config space is not really a critical feature that's not a big issue.

Not sure why you assume extended config space (ECS) is not critical.
Ok, for a lot of stuff it does not matter.
But it is needed for some devices for full functionality.
E.g. for perfmon (family 0x10/extended inerrupts) extended config space access
is a prerequisite.

> So I don't think we want this special case code at all and should
> just rely on MMCONFIG.

Rely on something unreliable (due to buggy/incomplete BIOS)?
I don't think we should do this.

IMHO it is best to try to use MMCONFIG if it's working and to use
a fallback (e.g. CF8 ECS access for family 0x10) if available.


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

Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Andi Kleen]

> But it is needed for some devices for full functionality.

Examples? I can only think of PCI express error reporting, which
few drivers implement anyways and isn't really a show stopper
if it doesn't work. Besides I would be surprised if it even works
on the cheap desktop boards which have MCFG less BIOS.

> E.g. for perfmon (family 0x10/extended inerrupts) extended config space
> access is a prerequisite.

How so? 


>
> IMHO it is best to try to use MMCONFIG if it's working and to use
> a fallback (e.g. CF8 ECS access for family 0x10) if available.

We only put in workarounds if there is a serious problem otherwise (e.g. not 
booting etc.). I just don't see this here.

-Andi

Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Robert Richter]

Andi,

On 03.09.07 12:15:03, Andi Kleen wrote:

> > But it is needed for some devices for full functionality.
> 
> Examples? I can only think of PCI express error reporting, which
> few drivers implement anyways and isn't really a show stopper
> if it doesn't work. Besides I would be surprised if it even works
> on the cheap desktop boards which have MCFG less BIOS.

As you say, there are BIOSs that do not support MMCONFIG. Thus, CF8
access is not only a workaround to boot a system. There are systems
that really use CF8 access. Also, MMCONFIG depends on many conditions
that must match. Cfg space must be mapped, the memory must be E820
reserved, MCFG table must be set, access to MMCONFIG must be enabled
for the device. Many things that may fail and can partly not be fixed
by the OS.

> > E.g. for perfmon (family 0x10/extended inerrupts) extended config space
> > access is a prerequisite.
> 
> How so? 

Recent (10h) and upcomming CPU families make heavy use of PCI ext cfg
space for certain CPU features. Setup of the extended interupt local
vector table for IBS (used with Perfmon2) is one example. CPU
designers do not take care anymore if a feature is in the base or
extended config space. So access to PCI ECS is essential.

> > IMHO it is best to try to use MMCONFIG if it's working and to use
> > a fallback (e.g. CF8 ECS access for family 0x10) if available.
> 
> We only put in workarounds if there is a serious problem otherwise (e.g. not 
> booting etc.). I just don't see this here.

As said above, I do not see CF8 access as a workaround. I expect my
system to work in the same way also if MMCONFIG is not available.

-Robert

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center
email: robert.richter@amd.com

Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Andreas Herrmann]

On Mon, Sep 03, 2007 at 12:15:03PM +0200, Andi Kleen wrote:
> 
> > But it is needed for some devices for full functionality.
> 
> Examples? I can only think of PCI express error reporting, which
> few drivers implement anyways and isn't really a show stopper
> if it doesn't work. Besides I would be surprised if it even works
> on the cheap desktop boards which have MCFG less BIOS.

Sure, AER is one example.
I don't see why all other stuff in ECS is not worth reading or writing.
And I am not sure whether all server boards set up MCFG in the correct way.

> > E.g. for perfmon (family 0x10/extended inerrupts) extended config space
> > access is a prerequisite.
> 
> How so? 

E.g. access to the IBS control register needs ECS access on Barcelona.
I guess we have to wait until Robert sends his patches which contain
all details.

> >
> > IMHO it is best to try to use MMCONFIG if it's working and to use
> > a fallback (e.g. CF8 ECS access for family 0x10) if available.
> 
> We only put in workarounds if there is a serious problem otherwise (e.g. not 
> booting etc.). I just don't see this here.

The serious problem is you can't access PCI ECS if the BIOS does
not take care to (correctly) set up MCFG.
And unfortunately this is too often the case.

See for instance Robert Hancock's patch http://lkml.org/lkml/2007/5/30/2
to enable MMCONFIG access in certain cases where BIOS did not correctly
set up MCFG. Why are people working on such stuff if it is not serious
enough?

Barcelona just adds another way to access PCI ECS (besides MMCONFIG) and I
can't understand why this shouldn't be supported by Linux.

Do you have any suggestion how else to add support for PCI ECS access via
IO instructions for Barcelona?


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

Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Andi Kleen]

On Monday 03 September 2007 13:27, Robert Richter wrote:

> On 03.09.07 12:15:03, Andi Kleen wrote:
> > > But it is needed for some devices for full functionality.
> >
> > Examples? I can only think of PCI express error reporting, which
> > few drivers implement anyways and isn't really a show stopper
> > if it doesn't work. Besides I would be surprised if it even works
> > on the cheap desktop boards which have MCFG less BIOS.
>
> As you say, there are BIOSs that do not support MMCONFIG. Thus, CF8
> access is not only a workaround to boot a system. 

We're talking about accessing the extended part of config spaces. I'm not 
aware of any case where that is required to boot a system.

> Recent (10h) and upcomming CPU families make heavy use of PCI ext cfg
> space for certain CPU features. Setup of the extended interupt local
> vector table for IBS (used with Perfmon2) is one example. CPU
> designers do not take care anymore if a feature is in the base or
> extended config space. So access to PCI ECS is essential.

I don't think it's a big issue if IBS doesn't work on a few buggy BIOS
(which should hopefully become fewer anyways because Vista is out
which actually uses MCFG) 


> > > IMHO it is best to try to use MMCONFIG if it's working and to use
> > > a fallback (e.g. CF8 ECS access for family 0x10) if available.
> >
> > We only put in workarounds if there is a serious problem otherwise (e.g.
> > not booting etc.). I just don't see this here.
>
> As said above, I do not see CF8 access as a workaround. I expect my
> system to work in the same way also if MMCONFIG is not available.

It should boot sure, but exotic stuff not working is not a major issue

-Andi

Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Andi Kleen]

> And unfortunately this is too often the case.

On Barcelona systems? 

> See for instance Robert Hancock's patch http://lkml.org/lkml/2007/5/30/2
> to enable MMCONFIG access in certain cases where BIOS did not correctly
> set up MCFG. Why are people working on such stuff if it is not serious
> enough?

I don't know why. I'm just not aware of any serious problems that
are solved by extended config space access.

Originally we had trouble because MCFG was wrong and the systems
would not boot. Also there is one class of systems (some x86 Apples) 
where cf8 doesn't work, but MMCONFIG does.
But that's all specific to older systems. 

> Barcelona just adds another way to access PCI ECS (besides MMCONFIG) and I
> can't understand why this shouldn't be supported by Linux.

It will be supported when the BIOS gets it right.

> Do you have any suggestion how else to add support for PCI ECS access via
> IO instructions for Barcelona?

My suggestion is to rely on MMCONFIG for this.

-Andi

Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Robert Richter]

Andi,

On 03.09.07 14:48:41, Andi Kleen wrote:

> > As said above, I do not see CF8 access as a workaround. I expect my
> > system to work in the same way also if MMCONFIG is not available.
>
> It should boot sure, but exotic stuff not working is not a major issue

It is not only about booting the system without MMCONFIG, it is also
about using the system. For this PCI ECS CF8 access is needed. So why
not adding support for this? Excluding major parts of CPU registers
when using CF8 base access only will cause writing code to workaround
this. Not very nice to handle.

-Robert

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center
email: robert.richter@amd.com

Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Andi Kleen]

On Monday 03 September 2007 15:48, Robert Richter wrote:
> Andi,
>
> On 03.09.07 14:48:41, Andi Kleen wrote:
> > > As said above, I do not see CF8 access as a workaround. I expect my
> > > system to work in the same way also if MMCONFIG is not available.
> >
> > It should boot sure, but exotic stuff not working is not a major issue
>
> It is not only about booting the system without MMCONFIG, it is also
> about using the system

There are limits on how many BIOS bug workaround (and all this
patch kit is nothing more than a elaborate BIOS bug workaround) we can do.
IMHO you're far exceeding the threshold.

Better would be to invest that energy to get the BIOSes fixed.

> . For this PCI ECS CF8 access is needed.

AER and IBS are all totally optional features and the systems
will be completely usable without them.

-Andi

Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Yinghai Lu]

On 9/3/07, Andi Kleen <ak@suse.de> wrote:
> On Monday 03 September 2007 13:27, Robert Richter wrote:
>
> > On 03.09.07 12:15:03, Andi Kleen wrote:
> > > > But it is needed for some devices for full functionality.
> > >
> > > Examples? I can only think of PCI express error reporting, which
> > > few drivers implement anyways and isn't really a show stopper
> > > if it doesn't work. Besides I would be surprised if it even works
> > > on the cheap desktop boards which have MCFG less BIOS.
> >
> > As you say, there are BIOSs that do not support MMCONFIG. Thus, CF8
> > access is not only a workaround to boot a system.
>
> We're talking about accessing the extended part of config spaces. I'm not
> aware of any case where that is required to boot a system.

in the bios for the new cpu, CF8 is used for ext conf space
accessing...(for ht and mem init).

for setting mmio to accessing pci conf space, need to set sth on MSR.
So the BIOS need to make it right..., otherwise OS need to set that
when booting every cpu...to workaround it to make MMCONFIG working.

YH

Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Andi Kleen]

> for setting mmio to accessing pci conf space, need to set sth on MSR.
> So the BIOS need to make it right..., otherwise OS need to set that
> when booting every cpu...to workaround it to make MMCONFIG working.

Yes the BIOS has to get some things right. After all that's the BIOS job.
And the BIOS knows much more about the hardware than the generic
kernel.  x86 Linux is not trying to be a BIOS too.

-Andi

Re: [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Arjan van de Ven]

On Mon, 03 Sep 2007 10:17:39 +0200
"Robert Richter" <robert.richter@amd.com> wrote:

> This patch implements PCI extended configuration space access for
> AMD's Barcelona CPUs. It extends the method using CF8/CFC IO
> addresses. An x86 capability bit has been introduced that is set for
> CPUs supporting PCI extended config space accesses.
> 


No offence but this feels a bit wrong to me.

PCI is sort of more a chipset property than a cpu property (I realize
that this boundary is changing of course).

I'd like to ask you to at least rename some of the feature bits to
indicate that the extended config space is for the IO access method;
after all Linux already supports the MMIO method for accessing extended
config space since a really long time; not marking the feature bit to
indicate it's the IO method is going to be extremely confusing and
cause bugs I bet.

(we probably need a global function that drivers can use to find out of
extended config space is accessible; however that for sure isn't a CPU
capability bit. However the current naming etc sort of makes me fear
drivers will abuse this thing while thinking it's the right API)

[patch 3/5] x86: Add PCI extended config space access for AMD Barcelona

[Robert Richter]

[-- Attachment #1: fam10h-pci-ext-cfg-io.diff --]
[-- Type: text/plain, Size: 7415 bytes --]

This patch implements PCI extended configuration space access for
AMD's Barcelona CPUs. It extends the method using CF8/CFC IO
addresses. An x86 capability bit has been introduced that is set for
CPUs supporting PCI extended config space accesses.

Signed-off-by: Robert Richter <robert.richter@amd.com>

---
 arch/i386/kernel/cpu/amd.c    |   11 +++++-
 arch/i386/pci/direct.c        |   67 +++++++++++++++++++++++++++++++++++-------
 arch/x86_64/kernel/setup.c    |   12 ++++++-
 include/asm-i386/cpufeature.h |    2 +
 4 files changed, 77 insertions(+), 15 deletions(-)

Index: linux-2.6/arch/i386/pci/direct.c
===================================================================
--- linux-2.6.orig/arch/i386/pci/direct.c
+++ linux-2.6/arch/i386/pci/direct.c
@@ -8,18 +8,22 @@
 #include "pci.h"
 
 /*
- * Functions for accessing PCI configuration space with type 1 accesses
+ * Functions for accessing PCI base (first 256 bytes) and extended
+ * (4096 bytes per PCI function) configuration space with type 1
+ * accesses.
  */
 
 #define PCI_CONF1_ADDRESS(bus, devfn, reg) \
-	(0x80000000 | (bus << 16) | (devfn << 8) | (reg & ~3))
+	(0x80000000 | ((reg & 0xF00) << 16) | (bus << 16) \
+	| (devfn << 8) | (reg & 0xFC))
 
-int pci_conf1_read(unsigned int seg, unsigned int bus,
-			  unsigned int devfn, int reg, int len, u32 *value)
+static inline int
+_pci_conf1ext_read(unsigned int seg, unsigned int bus,
+		   unsigned int devfn, int reg, int len, u32 *value)
 {
 	unsigned long flags;
 
-	if ((bus > 255) || (devfn > 255) || (reg > 255)) {
+	if ((bus > 255) || (devfn > 255) || (reg > 4095)) {
 		*value = -1;
 		return -EINVAL;
 	}
@@ -45,12 +49,29 @@ int pci_conf1_read(unsigned int seg, uns
 	return 0;
 }
 
-int pci_conf1_write(unsigned int seg, unsigned int bus,
-			   unsigned int devfn, int reg, int len, u32 value)
+int pci_conf1ext_read(unsigned int seg, unsigned int bus,
+		      unsigned int devfn, int reg, int len, u32 *value)
+{
+	return _pci_conf1ext_read(seg, bus, devfn, reg, len, value);
+}
+
+int pci_conf1_read(unsigned int seg, unsigned int bus,
+			  unsigned int devfn, int reg, int len, u32 *value)
+{
+	if (reg > 255) {
+		*value = -1;
+		return -EINVAL;
+	}
+	return _pci_conf1ext_read(seg, bus, devfn, reg, len, value);
+}
+
+static inline int
+_pci_conf1ext_write(unsigned int seg, unsigned int bus,
+		    unsigned int devfn, int reg, int len, u32 value)
 {
 	unsigned long flags;
 
-	if ((bus > 255) || (devfn > 255) || (reg > 255)) 
+	if ((bus > 255) || (devfn > 255) || (reg > 4095))
 		return -EINVAL;
 
 	spin_lock_irqsave(&pci_config_lock, flags);
@@ -74,6 +95,20 @@ int pci_conf1_write(unsigned int seg, un
 	return 0;
 }
 
+int pci_conf1ext_write(unsigned int seg, unsigned int bus,
+		       unsigned int devfn, int reg, int len, u32 value)
+{
+	return _pci_conf1ext_write(seg, bus, devfn, reg, len, value);
+}
+
+int pci_conf1_write(unsigned int seg, unsigned int bus,
+		 unsigned int devfn, int reg, int len, u32 value)
+{
+	if (reg > 255)
+		return -EINVAL;
+	return _pci_conf1ext_write(seg, bus, devfn, reg, len, value);
+}
+
 #undef PCI_CONF1_ADDRESS
 
 struct pci_raw_ops pci_direct_conf1 = {
@@ -81,6 +116,11 @@ struct pci_raw_ops pci_direct_conf1 = {
 	.write =	pci_conf1_write,
 };
 
+struct pci_raw_ops pci_direct_conf1ext = {
+	.read =		pci_conf1ext_read,
+	.write =	pci_conf1ext_write,
+};
+
 
 /*
  * Functions for accessing PCI configuration space with type 2 accesses
@@ -259,10 +299,15 @@ void __init pci_direct_init(int type)
 	if (type == 0)
 		return;
 	printk(KERN_INFO "PCI: Using configuration type %d\n", type);
-	if (type == 1)
-		raw_pci_ops = &pci_direct_conf1;
-	else
+	if (type != 1) {
 		raw_pci_ops = &pci_direct_conf2;
+	} else if (cpu_has_pci_ext_cfg) {
+		printk(KERN_INFO
+		       "PCI: Extended configuration space enabled\n");
+		raw_pci_ops = &pci_direct_conf1ext;
+	} else {
+		raw_pci_ops = &pci_direct_conf1;
+	}
 }
 
 int __init pci_direct_probe(void)
Index: linux-2.6/arch/x86_64/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86_64/kernel/setup.c
+++ linux-2.6/arch/x86_64/kernel/setup.c
@@ -65,6 +65,8 @@
 #include <asm/sections.h>
 #include <asm/dmi.h>
 
+#define ENABLE_CF8_EXT_CFG		(1ULL << 46)
+
 /*
  * Machine setup..
  */
@@ -549,10 +551,9 @@ static void __init amd_detect_cmp(struct
 static void __cpuinit init_amd(struct cpuinfo_x86 *c)
 {
 	unsigned level;
-
-#ifdef CONFIG_SMP
 	unsigned long value;
 
+#ifdef CONFIG_SMP
 	/*
 	 * Disable TLB flush filter by setting HWCR.FFDIS on K8
 	 * bit 6 of msr C001_0015
@@ -617,6 +618,13 @@ static void __cpuinit init_amd(struct cp
 	/* Family 10 doesn't support C states in MWAIT so don't use it */
 	if (c->x86 == 0x10 && !force_mwait)
 		clear_bit(X86_FEATURE_MWAIT, &c->x86_capability);
+
+	/* Access to PCI extended config space? */
+	if (c->x86 == 0x10) {
+		rdmsrl(MSR_AMD64_NB_CFG, value);
+		if (value & ENABLE_CF8_EXT_CFG)
+			set_bit(X86_FEATURE_PCI_EXT_CFG, &c->x86_capability);
+	}
 }
 
 static void __cpuinit detect_ht(struct cpuinfo_x86 *c)
Index: linux-2.6/include/asm-i386/cpufeature.h
===================================================================
--- linux-2.6.orig/include/asm-i386/cpufeature.h
+++ linux-2.6/include/asm-i386/cpufeature.h
@@ -82,6 +82,7 @@
 /* 14 free */
 #define X86_FEATURE_SYNC_RDTSC	(3*32+15)  /* RDTSC synchronizes the CPU */
 #define X86_FEATURE_REP_GOOD   (3*32+16) /* rep microcode works well on this CPU */
+#define X86_FEATURE_PCI_EXT_CFG	(3*32+17) /* PCI extended cfg access */
 
 /* Intel-defined CPU features, CPUID level 0x00000001 (ecx), word 4 */
 #define X86_FEATURE_XMM3	(4*32+ 0) /* Streaming SIMD Extensions-3 */
@@ -164,6 +165,7 @@
 #define cpu_has_pebs 		boot_cpu_has(X86_FEATURE_PEBS)
 #define cpu_has_clflush		boot_cpu_has(X86_FEATURE_CLFLSH)
 #define cpu_has_bts 		boot_cpu_has(X86_FEATURE_BTS)
+#define cpu_has_pci_ext_cfg	boot_cpu_has(X86_FEATURE_PCI_EXT_CFG)
 
 #endif /* __ASM_I386_CPUFEATURE_H */
 
Index: linux-2.6/arch/i386/kernel/cpu/amd.c
===================================================================
--- linux-2.6.orig/arch/i386/kernel/cpu/amd.c
+++ linux-2.6/arch/i386/kernel/cpu/amd.c
@@ -32,6 +32,7 @@ __asm__(".align 4\nvide: ret");
 #define CPUID_XFAM_11H          0x00200000
 #define CPUID_XMOD              0x000f0000
 #define CPUID_XMOD_REV_F        0x00040000
+#define ENABLE_CF8_EXT_CFG      (1ULL << 46)
 
 /* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
 static __cpuinit int amd_apic_timer_broken(void)
@@ -63,10 +64,9 @@ static void __cpuinit init_amd(struct cp
 	u32 l, h;
 	int mbytes = num_physpages >> (20-PAGE_SHIFT);
 	int r;
-
-#ifdef CONFIG_SMP
 	unsigned long long value;
 
+#ifdef CONFIG_SMP
 	/* Disable TLB flush filter by setting HWCR.FFDIS on K8
 	 * bit 6 of msr C001_0015
 	 *
@@ -296,6 +296,13 @@ static void __cpuinit init_amd(struct cp
 	/* K6s reports MCEs but don't actually have all the MSRs */
 	if (c->x86 < 6)
 		clear_bit(X86_FEATURE_MCE, c->x86_capability);
+
+	/* Access to PCI extended config space? */
+	if (c->x86 == 0x10) {
+		rdmsrl(MSR_AMD64_NB_CFG, value);
+		if (value & ENABLE_CF8_EXT_CFG)
+			set_bit(X86_FEATURE_PCI_EXT_CFG, c->x86_capability);
+	}
 }
 
 static unsigned int __cpuinit amd_size_cache(struct cpuinfo_x86 * c, unsigned int size)

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center
email: robert.richter@amd.com