x86_64: Rename IOMMU option, fix help and mark option embedded.
Subsystems (3)
PATCH 29/82 x86_64: Rename IOMMU option, fix help and mark option embedded.
- Rename the GART_IOMMU option to IOMMU to make clear it's not just for AMD
- Rewrite the help text to better emphatise this fact
- Make it an embedded option because too many people get it wrong.
To my astonishment I discovered the aacraid driver tests this symbol directly. This looks quite broken to me - it's an internal implementation detail of the PCI DMA API. Can the maintainer please clarify what this test was intended to do?
--- arch/x86_64/Kconfig | 28 +++++++++++++++------------- arch/x86_64/Kconfig.debug | 2 +- arch/x86_64/kernel/Makefile | 2 +- arch/x86_64/kernel/io_apic.c | 2 +- arch/x86_64/kernel/pci-dma.c | 2 +- arch/x86_64/kernel/setup.c | 2 +- drivers/char/agp/Kconfig | 4 ++-- drivers/char/agp/amd64-agp.c | 4 ++-- drivers/scsi/aacraid/comminit.c | 5 ++++- include/asm-x86_64/pci.h | 2 +- include/asm-x86_64/proto.h | 2 +- 11 files changed, 30 insertions(+), 25 deletions(-)
arch/x86_64/Kconfig +15 -13
@@ -386,24 +386,26 @@ config HPET_EMULATE_RTC bool "Provide RTC interrupt" depends on HPET_TIMER && RTC=y -config GART_IOMMU - bool "K8 GART IOMMU support" +# Mark as embedded because too many people got it wrong. +# The code disables itself when not needed. +config IOMMU + bool "IOMMU support" if EMBEDDED default y select SWIOTLB select AGP depends on PCI help - Support for hardware IOMMU in AMD's Opteron/Athlon64 Processors - and for the bounce buffering software IOMMU. - Needed to run systems with more than 3GB of memory properly with - 32-bit PCI devices that do not support DAC (Double Address Cycle). - The IOMMU can be turned off at runtime with the iommu=off parameter. - Normally the kernel will take the right choice by itself. - This option includes a driver for the AMD Opteron/Athlon64 IOMMU - northbridge and a software emulation used on other systems without - hardware IOMMU. If unsure, say Y. + Support for full DMA access of devices with 32bit memory access only + on systems with more than 3GB. This is usually needed for USB, + sound, many IDE/SATA chipsets and some other devices. + Provides a driver for the AMD Athlon64/Opteron/Turion/Sempron GART + based IOMMU and a software bounce buffer based IOMMU used on Intel + systems and as fallback. + The code is only active when needed (enough memory and limited + device) unless CONFIG_IOMMU_DEBUG or iommu=force is specified + too. -# need this always selected by GART_IOMMU for the VIA workaround +# need this always selected by IOMMU for the VIA workaround config SWIOTLB bool
@@ -503,7 +505,7 @@ config REORDER config K8_NB def_bool y - depends on AGP_AMD64 || GART_IOMMU || (PCI && NUMA) + depends on AGP_AMD64 || IOMMU || (PCI && NUMA) endmenu
arch/x86_64/Kconfig.debug +1 -1
@@ -13,7 +13,7 @@ config DEBUG_RODATA If in doubt, say "N". config IOMMU_DEBUG - depends on GART_IOMMU && DEBUG_KERNEL + depends on IOMMU && DEBUG_KERNEL bool "Enable IOMMU debugging" help Force the IOMMU to on even when you have less than 4GB of
arch/x86_64/kernel/Makefile +1 -1
@@ -28,7 +28,7 @@ obj-$(CONFIG_PM) += suspend.o obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend_asm.o obj-$(CONFIG_CPU_FREQ) += cpufreq/ obj-$(CONFIG_EARLY_PRINTK) += early_printk.o -obj-$(CONFIG_GART_IOMMU) += pci-gart.o aperture.o +obj-$(CONFIG_IOMMU) += pci-gart.o aperture.o obj-$(CONFIG_SWIOTLB) += pci-swiotlb.o obj-$(CONFIG_KPROBES) += kprobes.o obj-$(CONFIG_X86_PM_TIMER) += pmtimer.o
arch/x86_64/kernel/io_apic.c +1 -1
@@ -319,7 +319,7 @@ void __init check_ioapic(void) vendor &=0xffff ;switch (vendor) {case PCI_VENDOR_ID_VIA : -#ifdef CONFIG_GART_IOMMU +#ifdef CONFIG_IOMMU if ((end_pfn >MAX_DMA32_PFN || force_iommu) && !iommu_aperture_allowed) {
arch/x86_64/kernel/pci-dma.c +1 -1
@@ -266,7 +266,7 @@ __init int iommu_setup(char *p) swiotlb =1 ;#endif -#ifdef CONFIG_GART_IOMMU +#ifdef CONFIG_IOMMU gart_parse_options (p);#endif
arch/x86_64/kernel/setup.c +1 -1
@@ -797,7 +797,7 @@ void __init setup_arch(char **cmdline_p)e820_setup_gap (); -#ifdef CONFIG_GART_IOMMU +#ifdef CONFIG_IOMMU iommu_hole_init ();#endif
drivers/char/agp/Kconfig +2 -2
@@ -55,9 +55,9 @@ config AGP_AMD X on AMD Irongate, 761, and 762 chipsets. config AGP_AMD64 - tristate "AMD Opteron/Athlon64 on-CPU GART support" if !GART_IOMMU + tristate "AMD Opteron/Athlon64 on-CPU GART support" if !IOMMU depends on AGP && X86 - default y if GART_IOMMU + default y if IOMMU help This option gives you AGP support for the GLX component of X using the on-CPU northbridge of the AMD Athlon64/Opteron CPUs.
drivers/char/agp/amd64-agp.c +2 -2
@@ -292,7 +292,7 @@ static int __devinit aperture_valid(u64/* * W*s centric BIOS sometimes only set up the aperture in the AGP * bridge, not the northbridge. On AMD64 this is handled early -* in aperture.c, but when GART_IOMMU is not enabled or we run +* in aperture.c, but when IOMMU is not enabled or we run * on a 32bit kernel this needs to be redone. * Unfortunately it is impossible to fix the aperture here because it's too late * to allocate that much memory. But at least error out cleanly instead of
@@ -775,7 +775,7 @@ static void __exit agp_amd64_cleanup(voi/* On AMD64 the PCI driver needs to initialize this driver early for the IOMMU, so it has to be called via a backdoor. */ -#ifndef CONFIG_GART_IOMMU +#ifndef CONFIG_IOMMU module_init (agp_amd64_init);module_exit (agp_amd64_cleanup);#endif
drivers/scsi/aacraid/comminit.c +4 -1
@@ -104,8 +104,11 @@ static int aac_alloc_comm(struct aac_dev* always true on real computers. It also has some slight problems * with the GART on x86-64. I've btw never tried DMA from PCI space * on this platform but don't be surprised if its problematic. +* [AK: something is very very wrong when a driver tests this symbol. +* Someone should figure out what the comment writer really meant here and fix +* the code. Or just remove that bad code. ] */ -#ifndef CONFIG_GART_IOMMU +#ifndef CONFIG_IOMMU if ((num_physpages << (PAGE_SHIFT -12 )) <=AAC_MAX_HOSTPHYSMEMPAGES ) { init->HostPhysMemPages =cpu_to_le32 (num_physpages << (PAGE_SHIFT -12 ));
include/asm-x86_64/pci.h +1 -1
@@ -52,7 +52,7 @@ extern int iommu_setup(char *opt);*/ #define PCI_DMA_BUS_IS_PHYS (dma_ops->is_phys) -#ifdef CONFIG_GART_IOMMU +#ifdef CONFIG_IOMMU /* * x86-64 always supports DAC, but sometimes it is useful to force
include/asm-x86_64/proto.h +1 -1
@@ -116,7 +116,7 @@ extern int skip_ioapic_setup;extern int acpi_ht;extern int acpi_disabled; -#ifdef CONFIG_GART_IOMMU +#ifdef CONFIG_IOMMU extern int fallback_aper_order;extern int fallback_aper_force;extern int iommu_aperture;
Quoted 4 lines · Andi Kleen
To my astonishment I discovered the aacraid driver tests this symbol directly. This looks quite broken to me - it's an internal implementation detail of the PCI DMA API. Can the maintainer please clarify what this test was intended to do?
Shouldn't be to your astonishment, you were involved in the process
Older aacraid hardware cannot address the 3-4GB range where the iommu remaps pages. As the PCI DMA implementation for the x86-64 is flawed and doesn't support any nice way to deal with this via swiotlb instead the driver handles it internally.
Yeah its ugly, but its old hw and its a one off that can do without tangling the core code. At least thats what you decided last time around ;)
Quoted 7 lines · Alan Cox
Quoted 4 lines · Andi Kleen
To my astonishment I discovered the aacraid driver tests this symbol directly. This looks quite broken to me - it's an internal implementation detail of the PCI DMA API. Can the maintainer please clarify what this test was intended to do?
Shouldn't be to your astonishment, you were involved in the process
Can't remember sorry.
Quoted 4 lines
Older aacraid hardware cannot address the 3-4GB range where the iommu remaps pages. As the PCI DMA implementation for the x86-64 is flawed and doesn't support any nice way to deal with this via swiotlb instead the driver handles it internally.
Then you should just force a low bounce pfn < 0xfffffff for the block device - then the block layer should use GFP_DMA bouncing.
-Andi
Quoted 9 lines · Andi Kleen
Quoted 4 lines
Older aacraid hardware cannot address the 3-4GB range where the iommu remaps pages. As the PCI DMA implementation for the x86-64 is flawed and doesn't support any nice way to deal with this via swiotlb instead the driver handles it internally.
Then you should just force a low bounce pfn <
0xffffffffor the block device - then the block layer should useGFP_DMAbouncing.From a tiny 16MB DMA pool that can't sustain the required load ? Or has that
bit changed.
Alan
Quoted 11 lines · Alan Cox
Quoted 7 lines · Andi Kleen
Quoted 4 lines
Older aacraid hardware cannot address the 3-4GB range where the iommu remaps pages. As the PCI DMA implementation for the x86-64 is flawed and doesn't support any nice way to deal with this via swiotlb instead the driver handles it internally.
Then you should just force a low bounce pfn <
0xffffffffor the block device - then the block layer should useGFP_DMAbouncing.From a tiny 16MB DMA pool that can't sustain the required load ? Or has that bit changed.
It should be ok because it blocks. It will be slow, but what else do you expect from broken hardware like this?
-Andi
Quoted 5 lines · Andi Kleen
Quoted 2 lines
From a tiny 16MB DMA pool that can't sustain the required load ? Or has that bit changed.
It should be ok because it blocks. It will be slow, but what else do you expect from broken hardware like this?
Sustained 80Mbyte/second I/O rates. At least thats what it gets in other OS products. This is one of the reasons (broadcomm 4400 was another) that a 30 or 31 bit DMA zone not a 32bit one was called for, which also didn't happen it seems.
The ifdef approach isnt perfect but it essentially means you get good performance on x86-32 and only x86-64 has problems which seems fine to me, because its an old card.
Alan
Quoted 11 lines · Alan Cox
Quoted 5 lines · Andi Kleen
Quoted 2 lines
From a tiny 16MB DMA pool that can't sustain the required load ? Or has that bit changed.
It should be ok because it blocks. It will be slow, but what else do you expect from broken hardware like this?
Sustained 80Mbyte/second I/O rates. At least thats what it gets in other OS products. This is one of the reasons (broadcomm 4400 was another) that a 30 or 31 bit DMA zone not a 32bit one was called for, which also didn't happen it seems.
Should we hurt everybody for two terminally broken devices?
BCM4400 and its wireless brethen is fine with GFP_DMA btw and mostly only exists in low end machines where most/all of the memory is below 2GB anyways (so the check first approach works quite well)
Quoted 4 lines
The ifdef approach isnt perfect but it essentially means you get good performance on x86-32 and only x86-64 has problems which seems fine to me, because its an old card.
Blk-bounce would have the same effect.
If you set blk-bounce then the block layer will only bounce if the address is < limit and it knows about the different zones on 32bit and will use GFP_NORMAL there.
If you have upto 6GB you have a 50:50% chance of not bouncing at least.
The ifdef approach is just broken. Please fix it.
-Andi