Re: IOVA address range

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2023-10-30 6:19 pm, Bjorn Helgaas wrote:
[+cc folks from ./scripts/get_maintainer.pl -f drivers/iommu]

On Fri, Oct 27, 2023 at 12:17:17PM -0700, Eric Pilmore wrote:
Need a little IOVA/IOMMU help.

Is it correct that the IOVA address range for a device goes from
address 0x0 up to the dma-mask of the respective device?

Is it correct to assume that the base of the IOVA address space for a
device will always be zero (0x0)? Is there any reason to think that
this has changed in some newer iteration of the kernel, perhaps 5.10,
and that the base could be non-zero?

I realize an IOVA itself can be non-zero. I'm trying to verify what
the base address is of the IOVA space as a whole on a per device
basis.

In short, "No."

In detail, it depends on the architecture, since there are still a number of different IOMMU-based DMA API backends. Off-hand I do know that 32-bit Arm allocates upwards from 0, since there are some drivers annoyingly relying on that behaviour. I've never looked too closely at what the likes of Alpha, Sparc and PowerPC do. The generic IOVA allocator used by iommu-dma on x86, arm64, and soon s390, allocates top-down, but for historical reasons has a special behaviour for PCI devices where it tries to stay below the 32-bit boundary and only goes up to the full DMA mask (if larger) once that space is full. iommu-dma also always reserves 0 as an invalid IOVA - initially this was more of a convenience measure to help catch certain potential bugs, but it's long since also been relied upon as a special value in the internal caching mechanism. Note also that any device may have holes reserved anywhere in its otherwise-usable address space, and/or its entire notion of usable ranges constrained as described by firmware (e.g. a devicetree "dma-ranges" property or ACPI "_DMA" method).

Thanks,
Robin.



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux