• FUJITA Tomonori's avatar
    x86: Split swiotlb initialization into two stages · 186a2502
    FUJITA Tomonori authored
    The commit f4780ca0 moves
    swiotlb initialization before dma32_free_bootmem(). It's
    supposed to fix a bug that the commit
    75f1cdf1 introduced, we
    initialize SWIOTLB right after dma32_free_bootmem so we wrongly
    steal memory area allocated for GART with broken BIOS earlier.
    
    However, the above commit introduced another problem, which
    likely breaks machines with huge amount of memory. Such a box
    use the majority of DMA32_ZONE so there is no memory for
    swiotlb.
    
    With this patch, the x86 IOMMU initialization sequence are:
    
    1. We set swiotlb to 1 in the case of (max_pfn > MAX_DMA32_PFN
       && !no_iommu). If swiotlb usage is forced by the boot option,
       we go to the step 3 and finish (we don't try to detect IOMMUs).
    
    2. We call the detection functions of all the IOMMUs. The
       detection function sets x86_init.iommu.iommu_init to the IOMMU
       initialization function (so we can avoid calling the
       initialization functions of all the IOMMUs needlessly).
    
    3. We initialize swiotlb (and set dma_ops to swiotlb_dma_ops) if
       swiotlb is set to 1.
    
    4. If the IOMMU initialization function doesn't need swiotlb
       (e.g. the initialization is sucessful) then sets swiotlb to zero.
    
    5. If we find that swiotlb is set to zero, we free swiotlb
       resource.
    Reported-by: default avatarYinghai Lu <yinghai@kernel.org>
    Reported-by: default avatarRoland Dreier <rdreier@cisco.com>
    Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
    LKML-Reference: <20091215204729A.fujita.tomonori@lab.ntt.co.jp>
    Tested-by: default avatarYinghai Lu <yinghai@kernel.org>
    Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    186a2502
pci-swiotlb.c 1.78 KB