Skip to content

x86/iommu: Bootup stage cleanups

Thomas Gleixner linux-iommu lkml 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest5 patches 8 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/5x86, smpboot: Remove pointless preempt_disable() in native_smp_prepare_cpus()arch/x86/kernel/smpboot.c+1 -70 replies
2/5iommu, x86: Restructure setup of the irq remapping featurearch/x86/include/asm/irq_remapping.h arch/x86/kernel/apic/apic.c drivers/iommu/irq_remapping.c+7 -170 replies
3/5iommu/vt-d: Move iommu preparatory allocations to irq_remap_ops.preparedrivers/iommu/intel_irq_remapping.c+44 -207 replies
4/5irqdomain: Revert gfp hackerykernel/irq/irqdomain.c+2 -190 replies
5/5iommu/vt-d: Convert allocations to GFP_KERNELdrivers/iommu/intel_irq_remapping.c+2 -20 replies

Reviews trailers per patch

None of the 5 patches has a Reviewed-by or Acked-by of their own; the series has one for all of them.

PatchJoerg Roedel
SeriesA-b
1/5
2/5
3/5
4/5
5/5

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [patch 0/5] x86/iommu: Bootup stage cleanups

Boris reported that the conversion to stacked irqdomains causes a GFP_KERNEL allocation from atomic context splat.

The callchain is:

kernel_init_freeable
smp_prepare_cpus
default_setup_apic_routing
enable_IR_x2apic
irq_remapping_enable
intel_enable_irq_remapping
intel_setup_irq_remapping
irq_domain_add_hierarchy
__irq_domain_add

The reason for the splat is that smp_prepare_cpus() is pointlessly disabling preemption and enable_IR_x2apic is calling irq_remapping_enable with interrupts disabled.

Removing the completely useless preemption disable from smp_prepare_cpus() is a no brainer, but resolving the interrupt disabled issue in enable_IR_x2apic/irq_remapping_enable forced me to look deeper into the iommu setup code.

Convoluted is probably an euphemism for that maze.

The early detection of iommus happens in mem_init() which looks for the availability of ACPI tables describing iommus.

The actual parsing of the tables happens for AMD in setup_irq_remapping_ops() which calls remap_ops.prepare() and for Intel in irq_remapping_enable().

The AMD parsing allocates data structures, memory pages and the irq domain from the prepare callback, which makes a lot of sense as this has nothing to do with the actual enablement. That AMD code uses GFP_KERNEL allocations inside of a preempt disabled region. That issue is solved by removing the silly preempt_disable() from smp_prepare_cpus().

For Intel the actual parsing and allocation is moved from the enable to the prepare callback. That cures the reported splat and allows to use GFP_KERNEL allocations for the iommu internal stuff as well. While in the early bootup it does not matter much, for physical hotplug GFP_ATOMIC allocations are not desired at all.

That solves the issue at hand, but the iommu setup stays a tangled maze with completely non obvious setup mechanisms depending on the options (iommu on/off - irq remapping on/off).

Thanks,

tglx

---
 arch/x86/include/asm/irq_remapping.h |    2 -
 arch/x86/kernel/apic/apic.c          |    3 -
 arch/x86/kernel/smpboot.c            |    8 ----
 drivers/iommu/intel_irq_remapping.c  |   68 +++++++++++++++++++++++------------
 drivers/iommu/irq_remapping.c        |   19 +++------
 kernel/irq/irqdomain.c               |   21 +---------
 6 files changed, 56 insertions(+), 65 deletions(-)