Alexey Kardashevskiy <a...@ozlabs.ru> writes: > So far we have been using huge DMA windows to map all the RAM available. > The RAM is normally mapped to the VM address space contiguously, and > there is always a reasonable upper limit for possible future hot plugged > RAM which makes it easy to map all RAM via IOMMU. > > Now there is persistent memory ("ibm,pmemory" in the FDT) which (unlike > normal RAM) can map anywhere in the VM space beyond the maximum RAM size > and since it can be used for DMA, it requires extending the huge window > up to MAX_PHYSMEM_BITS which requires hypervisor support for: > 1. huge TCE tables; > 2. multilevel TCE tables; > 3. huge IOMMU pages. > > Certain hypervisors cannot do either so the only option left is > restricting the huge DMA window to include only RAM and fallback to > the default DMA window for persistent memory. > > This defines arch_dma_map_direct/etc to allow generic DMA code perform > additional checks on whether direct DMA is still possible. > > This checks if the system has persistent memory. If it does not, > the DMA bypass mode is selected, i.e. > * dev->bus_dma_limit = 0 > * dev->dma_ops_bypass = true <- this avoid calling dma_ops for mapping. > > If there is such memory, this creates identity mapping only for RAM and > sets the dev->bus_dma_limit to let the generic code decide whether to > call into the direct DMA or the indirect DMA ops. > > This should not change the existing behaviour when no persistent memory > as dev->dma_ops_bypass is expected to be set. > > Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru>
Acked-by: Michael Ellerman <m...@ellerman.id.au> cheers