x86/iommu: Bootup stage cleanups
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest5 patches 8 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/5 | x86, smpboot: Remove pointless preempt_disable() in native_smp_prepare_cpus()arch/ | +1 | 0 replies | |
| 2/5 | iommu, x86: Restructure setup of the irq remapping featurearch/ arch/ drivers/ | +7 | 0 replies | |
| 3/5 | iommu/vt-d: Move iommu preparatory allocations to irq_remap_ops.preparedrivers/ | +44 | 7 replies | |
| 4/5 | irqdomain: Revert gfp hackerykernel/ | +2 | 0 replies | |
| 5/5 | iommu/vt-d: Convert allocations to GFP_KERNELdrivers/ | +2 | 0 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.
| Patch | Joerg Roedel |
|---|---|
| Series | A-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.
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(-)