• Thomas Gleixner's avatar
    iommu/vt-d: Move iommu preparatory allocations to irq_remap_ops.prepare · 11190302
    Thomas Gleixner authored
    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: default avatarThomas Gleixner <tglx@linutronix.de>
    Tested-by: default avatarBorislav Petkov <bp@alien8.de>
    Acked-and-tested-by: default avatarJoerg Roedel <joro@8bytes.org>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: iommu@lists.linux-foundation.org
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Yinghai Lu <yinghai@kernel.org>
    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.comSigned-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    11190302
intel_irq_remapping.c 30.8 KB