22 Jan, 2015
19 commits
-
The UP local API support can be set up from an early initcall. No need
for horrible hackery in the init code.Signed-off-by: Thomas Gleixner
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/20150115211703.827943883@linutronix.de
Signed-off-by: Thomas Gleixner -
Move the code to a different place so we can make other functions
inline. Preparatory patch for further cleanups. No change.Signed-off-by: Thomas Gleixner
Acked-by: Borislav Petkov
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Link: http://lkml.kernel.org/r/20150115211703.731329006@linutronix.de
Signed-off-by: Thomas Gleixner -
smpboot is very creative with the ways to disable ioapic.
smpboot_clear_io_apic() smpboot_clear_io_apic_irqs() and
disable_ioapic_support() serve a similar purpose.smpboot_clear_io_apic_irqs() is the most useless of all
functions as it clears a variable which has not been setup yet.Aside of that it has the same ifdef mess and conditionals around the
ioapic related code, which can now be removed.Signed-off-by: Thomas Gleixner
Acked-by: Borislav Petkov
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Link: http://lkml.kernel.org/r/20150115211703.650280684@linutronix.de
Signed-off-by: Thomas Gleixner -
We have proper stubs for the IOAPIC=n case and the setup/enable
function have the required checks inside now. Remove the ifdeffery and
the copy&pasted conditionals.Signed-off-by: Thomas Gleixner C
Acked-by: Borislav Petkov
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Link: http://lkml.kernel.org/r/20150115211703.569830549@linutronix.de
Signed-off-by: Thomas Gleixner -
No point to have the same checks at every call site. Add them to the
functions, so they can be called unconditionally.Signed-off-by: Thomas Gleixner
Acked-by: Borislav Petkov
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Link: http://lkml.kernel.org/r/20150115211703.490719938@linutronix.de
Signed-off-by: Thomas Gleixner -
To avoid lots of ifdeffery provide proper stubs for setup_IO_APIC(),
enable_IO_APIC() and setup_ioapic_dest().Signed-off-by: Thomas Gleixner
Acked-by: Borislav Petkov
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Link: http://lkml.kernel.org/r/20150115211703.397170414@linutronix.de
Signed-off-by: Thomas Gleixner -
No point for a separate header file.
Signed-off-by: Thomas Gleixner
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/20150115211703.304126687@linutronix.de
Signed-off-by: Thomas Gleixner -
Use the state information to simplify the disable logic further.
Signed-off-by: Thomas Gleixner
Acked-by: Borislav Petkov
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Link: http://lkml.kernel.org/r/20150115211703.209387598@linutronix.de
Signed-off-by: Thomas Gleixner -
enable_x2apic() is a convoluted unreadable mess because it is used for
both enablement in early boot and for setup in cpu_init().Split the code into x2apic_enable() for enablement and x2apic_setup()
for setup of (secondary cpus). Make use of the new state tracking to
simplify the logic.Signed-off-by: Thomas Gleixner
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/20150115211703.129287153@linutronix.de
Signed-off-by: Thomas Gleixner -
There is no point in postponing the hardware disablement of x2apic. It
can be disabled right away in the nox2apic setup function.Disable it right away and set the state to DISABLED . This allows to
remove all the nox2apic conditionals all over the place.Signed-off-by: Thomas Gleixner
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/20150115211703.051214090@linutronix.de
Signed-off-by: Thomas Gleixner -
Having 3 different variables to track the state is just silly and
error prone. Add a proper state tracking variable which covers the
three possible states: ON/OFF/DISABLED.We cannot use x2apic_mode for this as this would require to change all
users of x2apic_mode with explicit comparisons for a state value
instead of treating it as boolean.Signed-off-by: Thomas Gleixner
Acked-by: Borislav Petkov
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Link: http://lkml.kernel.org/r/20150115211702.955392443@linutronix.de
Signed-off-by: Thomas Gleixner -
Rename the argument of try_to_enable_x2apic() so the purpose becomes
more clear.Make the pr_warning more consistent and avoid the double print of
"disabling".Signed-off-by: Thomas Gleixner
Acked-by: Borislav Petkov
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Link: http://lkml.kernel.org/r/20150115211702.876012628@linutronix.de
Signed-off-by: Thomas Gleixner -
No point in having try_to_enable_x2apic() outside of the
CONFIG_X86_X2APIC section and having inline functions and more ifdefs
to deal with it. Move the code into the existing ifdef section and
remove the inline cruft.Fixup the printk about not enabling interrupt remapping as suggested
by Boris.Signed-off-by: Thomas Gleixner
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/20150115211702.795388613@linutronix.de
Signed-off-by: Thomas Gleixner -
No point in delaying the x2apic detection for the CONFIG_X86_X2APIC=n
case to enable_IR_x2apic(). We rather detect that before we try to
setup anything there.Signed-off-by: Thomas Gleixner
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/20150115211702.702479404@linutronix.de
Signed-off-by: Thomas Gleixner -
If x2apic_preenabled is not enabled, then disable_x2apic() is not
called from various places which results in x2apic_disabled not being
set. So other code pathes can happily reenable the x2apic.Signed-off-by: Thomas Gleixner
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/20150115211702.621431109@linutronix.de
Signed-off-by: Thomas Gleixner -
The x2apic_preenabled flag is just a horrible hack and if X2APIC
support is disabled it does not reflect the actual hardware
state. Check the hardware instead.Signed-off-by: Thomas Gleixner
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/20150115211702.541280622@linutronix.de
Signed-off-by: Thomas Gleixner -
Having several disjunct pieces of code for x2apic support makes
reading the code unnecessarily hard. Move it to one ifdeffed section.Signed-off-by: Thomas Gleixner
Acked-by: Borislav Petkov
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Link: http://lkml.kernel.org/r/20150115211702.445212133@linutronix.de
Signed-off-by: Thomas Gleixner -
No point in having a static variable around which is always 0. Let the
compiler optimize code out if disabled.Signed-off-by: Thomas Gleixner
Acked-by: Borislav Petkov
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Link: http://lkml.kernel.org/r/20150115211702.363274310@linutronix.de
Signed-off-by: Thomas Gleixner -
enable_IR_x2apic() grew a open coded x2apic detection. Implement a
proper helper function which shares the code with the already existing
x2apic_enabled().Made it use rdmsrl_safe as suggested by Boris.
Signed-off-by: Thomas Gleixner
Cc: Borislav Petkov
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Link: http://lkml.kernel.org/r/20150115211702.285038186@linutronix.de
Signed-off-by: Thomas Gleixner
15 Jan, 2015
18 commits
-
Refine code by normailizing the way to detect whether IR is enabled.
Signed-off-by: Jiang Liu
Tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/1420615903-28253-17-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
Change variable disable_irq_remap to be static and simplify the code.
Signed-off-by: Jiang Liu
Tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/1420615903-28253-16-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
Assign intel_irq_remap_ops to remap_ops only if
intel_irq_remap_ops.prepare() succeeds.Signed-off-by: Jiang Liu
Tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/1420615903-28253-15-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
Simplify irq_remapping code by killing irq_remapping_supported() and
related interfaces.Joerg posted a similar patch at https://lkml.org/lkml/2014/12/15/490,
so assume an signed-off from Joerg.Signed-off-by: Jiang Liu
Signed-off-by: Joerg Roedel
Tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: H. Peter Anvin
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Cc: David Rientjes
Cc: HATAYAMA Daisuke
Cc: Jan Beulich
Cc: Richard Weinberger
Cc: Oren Twaig
Link: http://lkml.kernel.org/r/1420615903-28253-14-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
This allows to get rid of the irq_remapping_supported() function and
all its call-backs into the Intel and AMD IOMMU drivers.Signed-off-by: Joerg Roedel
Signed-off-by: Jiang Liu
Tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/1420615903-28253-13-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
When interrupt remapping hardware is not in X2APIC, CPU X2APIC mode
will be disabled if:
1) Maximum CPU APIC ID is bigger than 255
2) hypervisior doesn't support x2apic mode.But we should only check whether hypervisor supports X2APIC mode when
hypervisor(CONFIG_HYPERVISOR_GUEST) is enabled, otherwise X2APIC will
always be disabled when CONFIG_HYPERVISOR_GUEST is disabled and IR
doesn't work in X2APIC mode.Signed-off-by: Jiang Liu
Tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: H. Peter Anvin
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Cc: David Rientjes
Cc: HATAYAMA Daisuke
Cc: Jan Beulich
Cc: Richard Weinberger
Cc: Oren Twaig
Link: http://lkml.kernel.org/r/1420615903-28253-12-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
Currently if CPU supports X2APIC, IR hardware must work in X2APIC mode
or disabled. Change the code to support IR working in XAPIC mode when
CPU supports X2APIC. Then the CPU APIC driver will decide how to handle
such as configuration by:
1) Disabling X2APIC mode
2) Forcing X2APIC physical modeThis change also fixes a live locking when
1) BIOS enables CPU X2APIC
2) DMAR table disables X2APIC mode or IR hardware doesn't support X2APIC
with following messages:
[ 37.863463] dmar: INTR-REMAP: Request device [[f0:1f.7] fault index 2
[ 37.863463] INTR-REMAP:[fault reason 36] Detected reserved fields in the IRTE entry
[ 37.879372] dmar: INTR-REMAP: Request device [[f0:1f.7] fault index 2
[ 37.879372] INTR-REMAP:[fault reason 36] Detected reserved fields in the IRTE entry
[ 37.895282] dmar: INTR-REMAP: Request device [[f0:1f.7] fault index 2
[ 37.895282] INTR-REMAP:[fault reason 36] Detected reserved fields in the IRTE entry
[ 37.911192] dmar: INTR-REMAP: Request device [[f0:1f.7] fault index 2Signed-off-by: Jiang Liu
Tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/1420615903-28253-11-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
IRQ remapping is only supported when all IOMMUs in the
system support it. So check if all IOMMUs in the system
support IRQ remapping before doing the allocations.[Jiang]
1) Rebased to v3.19.
2) Remove redundant check of ecap_ir_support(iommu->ecap) in function
intel_enable_irq_remapping().Signed-off-by: Joerg Roedel
Signed-off-by: Jiang Liu
Tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/1420615903-28253-10-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
Prepare for killing function irq_remapping_supported() by moving code
from intel_irq_remapping_supported() into intel_prepare_irq_remapping().Combined with patch from Joerg at https://lkml.org/lkml/2014/12/15/487,
so assume an signed-off from Joerg.Signed-off-by: Jiang Liu
Signed-off-by: Joerg Roedel
Tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/1420615903-28253-9-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
If remapping is in XAPIC mode, the setup code just skips X2APIC
initialization without checking max CPU APIC ID in system, which may
cause problem if system has a CPU with APIC ID bigger than 255.Handle IR in XAPIC mode the same way as if remapping is disabled.
[ tglx: Split out from previous patch ]
Signed-off-by: Jiang Liu
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: H. Peter Anvin
Cc: Joerg Roedel
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Cc: David Rientjes
Cc: HATAYAMA Daisuke
Cc: Jan Beulich
Cc: Richard Weinberger
Cc: Oren Twaig
Link: http://lkml.kernel.org/r/1420615903-28253-8-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
Refine enable_IR_x2apic() and related functions for better readability.
[ tglx: Removed the XAPIC mode change and split it out into a seperate
patch. Added comments. ]Signed-off-by: Jiang Liu
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: H. Peter Anvin
Cc: Joerg Roedel
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Cc: David Rientjes
Cc: HATAYAMA Daisuke
Cc: Jan Beulich
Cc: Richard Weinberger
Cc: Oren Twaig
Link: http://lkml.kernel.org/r/1420615903-28253-8-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
X2APIC will be disabled if user specifies "nox2apic" on kernel command
line, even when x2apic_preenabled is true. So correctly detect X2APIC
status by using x2apic_enabled() instead of x2apic_preenabled.Signed-off-by: Jiang Liu
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: H. Peter Anvin
Cc: Joerg Roedel
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Cc: David Rientjes
Cc: HATAYAMA Daisuke
Cc: Jan Beulich
Cc: Richard Weinberger
Cc: Oren Twaig
Link: http://lkml.kernel.org/r/1420615903-28253-7-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
Local variable x2apic_enabled has been assigned to but never referred,
so kill it.Signed-off-by: Jiang Liu
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: H. Peter Anvin
Cc: Joerg Roedel
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Cc: David Rientjes
Cc: HATAYAMA Daisuke
Cc: Jan Beulich
Cc: Richard Weinberger
Cc: Oren Twaig
Link: http://lkml.kernel.org/r/1420615903-28253-6-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
When kernel doesn't support X2APIC but BIOS has enabled X2APIC, system
may panic or hang without useful messages. On the other hand, it's
hard to dynamically disable X2APIC when CONFIG_X86_X2APIC is disabled.
So panic with a clear message in such a case.Now system panics as below when X2APIC is disabled and interrupt remapping
is enabled:
[ 0.316118] LAPIC pending interrupts after 512 EOI
[ 0.322126] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.368655] Kernel panic - not syncing: timer doesn't work through Interrupt-remapped IO-APIC
[ 0.378300] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0+ #340
[ 0.385300] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIN1.86B.0051.L05.1406240953 06/24/2014
[ 0.396997] ffff88046dc03000 ffff88046c307dd8 ffffffff8179dada 00000000000043f2
[ 0.405629] ffffffff81a92158 ffff88046c307e58 ffffffff8179b757 0000000000000002
[ 0.414261] 0000000000000008 ffff88046c307e68 ffff88046c307e08 ffffffff813ad82b
[ 0.422890] Call Trace:
[ 0.425711] [] dump_stack+0x45/0x57
[ 0.431533] [] panic+0xc1/0x1f5
[ 0.436978] [] ? delay_tsc+0x3b/0x70
[ 0.442910] [] panic_if_irq_remap+0x1c/0x20
[ 0.449524] [] setup_IO_APIC+0x405/0x82e
[ 0.464979] [] native_smp_prepare_cpus+0x2d9/0x31c
[ 0.472274] [] kernel_init_freeable+0xd6/0x223
[ 0.479170] [] ? rest_init+0x80/0x80
[ 0.485099] [] kernel_init+0xe/0xf0
[ 0.490932] [] ret_from_fork+0x7c/0xb0
[ 0.497054] [] ? rest_init+0x80/0x80
[ 0.502983] ---[ end Kernel panic - not syncing: timer doesn't work through Interrupt-remapped IO-APICSystem hangs as below when X2APIC and interrupt remapping are both disabled:
[ 1.102782] pci 0000:00:02.0: System wakeup disabled by ACPI
[ 1.109351] pci 0000:00:03.0: System wakeup disabled by ACPI
[ 1.115915] pci 0000:00:03.2: System wakeup disabled by ACPI
[ 1.122479] pci 0000:00:03.3: System wakeup disabled by ACPI
[ 1.132274] pci 0000:00:1c.0: Enabling MPC IRBNCE
[ 1.137620] pci 0000:00:1c.0: Intel PCH root port ACS workaround enabled
[ 1.145239] pci 0000:00:1c.0: System wakeup disabled by ACPI
[ 1.151790] pci 0000:00:1c.7: Enabling MPC IRBNCE
[ 1.157128] pci 0000:00:1c.7: Intel PCH root port ACS workaround enabled
[ 1.164748] pci 0000:00:1c.7: System wakeup disabled by ACPI
[ 1.171447] pci 0000:00:1e.0: System wakeup disabled by ACPI
[ 1.178612] acpiphp: Slot [8] registered
[ 1.183095] pci 0000:00:02.0: PCI bridge to [bus 01]
[ 1.188867] acpiphp: Slot [2] registeredWith this patch applied, the system panics in both cases with a proper
panic message.Signed-off-by: Jiang Liu
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: H. Peter Anvin
Cc: Joerg Roedel
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Cc: David Rientjes
Cc: HATAYAMA Daisuke
Cc: Jan Beulich
Cc: Richard Weinberger
Cc: Oren Twaig
Link: http://lkml.kernel.org/r/1420615903-28253-5-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner -
If x2apic got disabled on the kernel command line, then the following
issue can happen:enable_IR_x2apic()
....
x2apic_mode = 1;
enable_x2apic();if (x2apic_disabled) {
__disable_x2apic();
return;
}That leaves X2APIC disabled in hardware, but x2apic_mode stays 1. So
all other code which checks x2apic_mode gets the wrong information.Set x2apic_mode to 0 after disabling it in hardware.
This is just a hotfix. The proper solution is to rework this code so
it has seperate functions for the initial setup on the boot processor
and the secondary cpus, but that's beyond the scope of this fix.Signed-off-by: Thomas Gleixner
Cc: Jiang Liu
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: H. Peter Anvin
Cc: Joerg Roedel
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Cc: David Rientjes
Cc: HATAYAMA Daisuke
Cc: Jan Beulich
Cc: Richard Weinberger
Cc: Oren Twaig -
No reason anymore to do GFP_ATOMIC allocations which are not harmful
in the normal bootup case, but matter in the physical hotplug
scenario.Signed-off-by: Thomas Gleixner
Tested-by: Borislav Petkov
Acked-and-tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20141205084147.472428339@linutronix.de
Link: http://lkml.kernel.org/r/1420615903-28253-4-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Jiang Liu
Signed-off-by: Thomas Gleixner -
The whole iommu setup for irq remapping is a convoluted mess. The
iommu detect function gets called from mem_init() and the prepare
callback gets called from enable_IR_x2apic() for unknown reasons.Of course AMD and Intel setup differs in nonsensical ways. Intels
prepare callback is explicit while AMDs prepare callback is implicit
in setup_irq_remapping_ops() just to be called in the prepare call
again.Because all of this gets called from enable_IR_x2apic() and the dmar
prepare function merily parses the ACPI tables, but does not allocate
memory we end up with memory allocation from irq disabled context
later on.AMDs iommu code at least allocates the required memory from the
prepare function. That has issues as well, but thats not scope of this
patch.The goal of this change is to distangle the allocation from the actual
enablement. There is no point to allocate memory from irq disabled
regions with GFP_ATOMIC just because it does not matter at that point
in the boot stage. It matters with physical hotplug later on.There is another issue with the current setup. Due to the conversion
to stacked irqdomains we end up with a call into the irqdomain
allocation code from irq disabled context, but that code does
GFP_KERNEL allocations rightfully as there is no reason to do
preperatory allocations with GFP_ATOMIC.That change caused the allocator code to complain about GFP_KERNEL
allocations invoked in atomic context. Boris provided a temporary
hackaround which changed the GFP flags if irq_domain_add() got called
from atomic context. Not pretty and we really dont want to get this
into a mainline release for obvious reasons.Move the ACPI table parsing and the resulting memory allocations from
the enable to the prepare function. That allows to get rid of the
horrible hackaround in irq_domain_add() later.[Jiang] Rebased onto v3.19
Signed-off-by: Thomas Gleixner
Tested-by: Borislav Petkov
Acked-and-tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20141205084147.313026156@linutronix.de
Link: http://lkml.kernel.org/r/1420615903-28253-3-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Jiang Liu
Signed-off-by: Thomas Gleixner -
enable_IR_x2apic() calls setup_irq_remapping_ops() which by default
installs the intel dmar remapping ops and then calls the amd iommu irq
remapping prepare callback to figure out whether we are running on an
AMD machine with irq remapping hardware.Right after that it calls irq_remapping_prepare() which pointlessly
checks:
if (!remap_ops || !remap_ops->prepare)
return -ENODEV;
and then callsremap_ops->prepare()
which is silly in the AMD case as it got called from
setup_irq_remapping_ops() already a few microseconds ago.Simplify this and just collapse everything into
irq_remapping_prepare().The irq_remapping_prepare() remains still silly as it assigns blindly
the intel ops, but that's not scope of this patch.The scope here is to move the preperatory work, i.e. memory
allocations out of the atomic section which is required to enable irq
remapping.Signed-off-by: Thomas Gleixner
Tested-by: Borislav Petkov
Acked-and-tested-by: Joerg Roedel
Cc: Tony Luck
Cc: iommu@lists.linux-foundation.org
Cc: Joerg Roedel
Cc: H. Peter Anvin
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: David Rientjes
Cc: HATAYAMA Daisuke
Cc: Jan Beulich
Cc: Richard Weinberger
Cc: Oren Twaig
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20141205084147.232633738@linutronix.de
Link: http://lkml.kernel.org/r/1420615903-28253-2-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Jiang Liu
Signed-off-by: Thomas Gleixner
12 Jan, 2015
3 commits
-
Pull ARM fixes from Russell King:
"Three small fixes from over the Christmas period, and wiring up the
new execveat syscall for ARM"* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
ARM: 8275/1: mm: fix PMD_SECT_RDONLY undeclared compile error
ARM: 8253/1: mm: use phys_addr_t type in map_lowmem() for kernel mem region
ARM: 8249/1: mm: dump: don't skip regions
ARM: wire up execveat syscall -
Pull x86 fixes from Ingo Molnar:
"Misc fixes: two vdso fixes, two kbuild fixes and a boot failure fix
with certain odd memory mappings"* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, vdso: Use asm volatile in __getcpu
x86/build: Clean auto-generated processor feature files
x86: Fix mkcapflags.sh bash-ism
x86: Fix step size adjustment during initial memory mapping
x86_64, vdso: Fix the vdso address randomization algorithm
