[+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.
>
> Thanks,
> Eric Pilmore
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.