Prev: KVM: SVM: Sync cr0 and cr3 to kvm state before nested handling
Next: Mass storage gadget: Handle eject request
From: Borislav Petkov on 23 Apr 2010 10:20
From: Borislav Petkov <bp(a)amd64.org>
Date: Fri, Apr 23, 2010 at 08:50:16AM +0200

> > I get compilation failures on tip:x86/cpu with this patchset:
> >
> > arch/x86/built-in.o: In function `amd_check_l3_disable':
> > intel_cacheinfo.c:(.cpuinit.text+0x412): undefined reference to
> > `num_k8_northbridges'
> >
> > Both i386 and x86-64 "make allnoconfig".
>
> Yeah, this has bitten us already several times in the past. allnoconfig
> deselects CONFIG_PCI and num_k8_northbridges is under CONFIG_K8_NB which
> depends on CONFIG_PCI so there you go.
>
> I'm thinking the k8.c facility is needed more and more for all the
> processor functionality control over the PCI config space so how about
> compile it in unconditionally on AMD? All the k8's and F10h's need
> it and the older ones will have it there but it won't hurt since the
> pci_get_device() won't match any on those.
>
> allnoconfig build failure is fixed this way, albeit non-functional since
> CONFIG_PCI is off and pci_get_device() returns NULL but in that case
> almost all of the functionality (I guess raw PCI access would still
> work) depending on AMD northbridge PCI devices won't work anyway.
>
> I'll prep something in a while.

Ok, looking at the k8.o object it is 507 bytes so I don't think
compiling it in would hurt embedded people too much:

text data bss dec hex filename
379 104 24 507 1fb arch/x86/kernel/k8.o

So how about the following? It should apply cleanly on top and it
survived a bunch of randconfigs here so far.

---
From: Borislav Petkov <borislav.petkov(a)amd.com>
Date: Fri, 23 Apr 2010 14:05:50 +0200
Subject: [PATCH] x86, AMD: Build in Northbridge PCI config devices support

A bunch of facilities in the kernel depend on accessing the processor's
PCI config space in the northbridge for configuration and control. All
K8 and F10h processors have that config space so build in the facility
in k8.c which takes care of enumerating those PCI devices by default on
AMD.

Signed-off-by: Borislav Petkov <borislav.petkov(a)amd.com>
---
arch/x86/Kconfig | 6 +-----
arch/x86/kernel/Makefile | 1 -
arch/x86/kernel/cpu/Makefile | 2 +-
drivers/char/agp/Kconfig | 2 +-
drivers/edac/Kconfig | 2 +-
include/linux/pci.h | 4 ++++
6 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9458685..9f80658 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -662,7 +662,7 @@ config GART_IOMMU
bool "GART IOMMU support" if EMBEDDED
default y
select SWIOTLB
- depends on X86_64 && PCI && K8_NB
+ depends on X86_64 && PCI
---help---
Support for full DMA access of devices with 32bit memory access only
on systems with more than 3GB. This is usually needed for USB,
@@ -2059,10 +2059,6 @@ config OLPC

endif # X86_32

-config K8_NB
- def_bool y
- depends on CPU_SUP_AMD && PCI
-
source "drivers/pcmcia/Kconfig"

source "drivers/pci/hotplug/Kconfig"
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 4c58352..1afad06 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -89,7 +89,6 @@ obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
obj-$(CONFIG_HPET_TIMER) += hpet.o
obj-$(CONFIG_APB_TIMER) += apb_timer.o

-obj-$(CONFIG_K8_NB) += k8.o
obj-$(CONFIG_DEBUG_RODATA_TEST) += test_rodata.o
obj-$(CONFIG_DEBUG_NX_TEST) += test_nx.o

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index c202b62..78ef6c0 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_X86_32) += bugs.o cmpxchg.o
obj-$(CONFIG_X86_64) += bugs_64.o

obj-$(CONFIG_CPU_SUP_INTEL) += intel.o
-obj-$(CONFIG_CPU_SUP_AMD) += amd.o
+obj-$(CONFIG_CPU_SUP_AMD) += amd.o ../k8.o
obj-$(CONFIG_CPU_SUP_CYRIX_32) += cyrix.o
obj-$(CONFIG_CPU_SUP_CENTAUR) += centaur.o
obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig
index 4b66c69..2fb3a48 100644
--- a/drivers/char/agp/Kconfig
+++ b/drivers/char/agp/Kconfig
@@ -57,7 +57,7 @@ config AGP_AMD

config AGP_AMD64
tristate "AMD Opteron/Athlon64 on-CPU GART support"
- depends on AGP && X86 && K8_NB
+ depends on AGP && X86
help
This option gives you AGP support for the GLX component of
X using the on-CPU northbridge of the AMD Athlon64/Opteron CPUs.
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 55c9c59..0812bbf 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -71,7 +71,7 @@ config EDAC_MM_EDAC

config EDAC_AMD64
tristate "AMD64 (Opteron, Athlon64) K8, F10h, F11h"
- depends on EDAC_MM_EDAC && K8_NB && X86_64 && PCI && EDAC_DECODE_MCE
+ depends on EDAC_MM_EDAC && X86_64 && PCI && EDAC_DECODE_MCE
help
Support for error detection and correction on the AMD 64
Families of Memory Controllers (K8, F10h and F11h)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index a788fa1..150dd65 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1199,6 +1199,10 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
unsigned int devfn)
{ return NULL; }

+static inline const struct pci_device_id *pci_match_id(const struct pci_device_id *ids,
+ struct pci_dev *dev)
+{ return NULL; }
+
#define dev_is_pci(d) (false)
#define dev_is_pf(d) (false)
#define dev_num_vf(d) (0)
--
1.6.4.4


--
Regards/Gruss,
Boris.

--
Advanced Micro Devices, Inc.
Operating Systems Research Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 23 Apr 2010 14:10
On 04/23/2010 07:09 AM, Borislav Petkov wrote:
>
> Ok, looking at the k8.o object it is 507 bytes so I don't think
> compiling it in would hurt embedded people too much:
>
> text data bss dec hex filename
> 379 104 24 507 1fb arch/x86/kernel/k8.o
>
> So how about the following? It should apply cleanly on top and it
> survived a bunch of randconfigs here so far.
>

I have to say I think that's pretty ridiculous for someone who cares so
much about size that they have disabled CONFIG_PCI that they can just
add another half-kilobyte of code that is going to do absolutely
nothing. Think about the kind of x86 CPUs that could even consider
disabling CONFIG_PCI -- we're talking pretty deep embedded by now.

So, no, I don't think this is an option. Force-enabling CONFIG_PCI on
x86 would be a more realistic option, and I honestly don't know how many
people would object to that, but not right now.

The obvious answer instead is to augment the list of stubs in
<asm/k8.h>. In particular, move num_k8_northbridges into the #ifdef and
just #define num_k8_northbridges 0 in the other clause.

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 22 Apr 2010 20:30
Hi Borislav,

I get compilation failures on tip:x86/cpu with this patchset:

arch/x86/built-in.o: In function `amd_check_l3_disable':
intel_cacheinfo.c:(.cpuinit.text+0x412): undefined reference to
`num_k8_northbridges'

Both i386 and x86-64 "make allnoconfig".

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Borislav Petkov on 23 Apr 2010 03:00
From: "H. Peter Anvin" <hpa(a)zytor.com>
Date: Thu, Apr 22, 2010 at 05:23:05PM -0700

> Hi Borislav,
>
> I get compilation failures on tip:x86/cpu with this patchset:
>
> arch/x86/built-in.o: In function `amd_check_l3_disable':
> intel_cacheinfo.c:(.cpuinit.text+0x412): undefined reference to
> `num_k8_northbridges'
>
> Both i386 and x86-64 "make allnoconfig".

Yeah, this has bitten us already several times in the past. allnoconfig
deselects CONFIG_PCI and num_k8_northbridges is under CONFIG_K8_NB which
depends on CONFIG_PCI so there you go.

I'm thinking the k8.c facility is needed more and more for all the
processor functionality control over the PCI config space so how about
compile it in unconditionally on AMD? All the k8's and F10h's need
it and the older ones will have it there but it won't hurt since the
pci_get_device() won't match any on those.

allnoconfig build failure is fixed this way, albeit non-functional since
CONFIG_PCI is off and pci_get_device() returns NULL but in that case
almost all of the functionality (I guess raw PCI access would still
work) depending on AMD northbridge PCI devices won't work anyway.

I'll prep something in a while.

--
Regards/Gruss,
Boris.

--
Advanced Micro Devices, Inc.
Operating Systems Research Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Borislav Petkov on 21 Apr 2010 16:50
From: Borislav Petkov <bp(a)amd64.org>
Date: Thu, Apr 15, 2010 at 06:40:58PM +0200

Ping.

It would be cool if we could sort out objections soon (in case there are
any, of course) so that the patches can have some -tip time before the
..35 merge window.

Thanks.

> From: Borislav Petkov <borislav.petkov(a)amd.com>
>
> Hi,
>
> this is a small patchset of fixes for L3 CID which have accumulated over
> the last couple of weeks. They serve as a preparation for disabling L3
> cache indices whenever an L3 MCE triggers, has been evaluated and the
> offending index thresholded and, if error rate is excessively high,
> disabled. Those patches will be coming up later though.
>
> Patches 1,3,4 are cleanups and unifications which save us a little bit
> of percpu memory in favor of dynamic allocation. Also, we have an L3
> cache descriptor per node now instead of having this information per
> CPU.
>
> I triggered a lockdep warning in lockdep_trace_alloc() during testing
> due to the fact that we may run with disabled interrupts that early
> in the boot process. Therefore, I have a GFP_ATOMIC in patch 3 there
> allocating the cache descriptors. I'm open for suggestions in case this
> is undesired.
>
> Patch 2 is a fix which triggers when we run as a guest on Xen due to Xen
> not exporting CPU PCI config space to the guests.
>
> And finally #5 is a required fix.
>
> The patchset is also available at
> git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git l3-for-35
>
> Please queue for .35,
> thanks.
>

--
Regards/Gruss,
Boris.

--
Advanced Micro Devices, Inc.
Operating Systems Research Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: KVM: SVM: Sync cr0 and cr3 to kvm state before nested handling
Next: Mass storage gadget: Handle eject request