public inbox for dmaengine@vger.kernel.org
 help / color / mirror / Atom feed
* IOVA address range
@ 2023-10-27 19:17 Eric Pilmore
  2023-10-30 18:19 ` Bjorn Helgaas
  0 siblings, 1 reply; 3+ messages in thread
From: Eric Pilmore @ 2023-10-27 19:17 UTC (permalink / raw)
  To: linux-pci, dmaengine; +Cc: Eric Pilmore

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: IOVA address range
  2023-10-27 19:17 IOVA address range Eric Pilmore
@ 2023-10-30 18:19 ` Bjorn Helgaas
  2023-10-31 11:46   ` Robin Murphy
  0 siblings, 1 reply; 3+ messages in thread
From: Bjorn Helgaas @ 2023-10-30 18:19 UTC (permalink / raw)
  To: Eric Pilmore
  Cc: linux-pci, dmaengine, Joerg Roedel, Will Deacon, Robin Murphy,
	iommu, linux-kernel

[+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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: IOVA address range
  2023-10-30 18:19 ` Bjorn Helgaas
@ 2023-10-31 11:46   ` Robin Murphy
  0 siblings, 0 replies; 3+ messages in thread
From: Robin Murphy @ 2023-10-31 11:46 UTC (permalink / raw)
  To: Bjorn Helgaas, Eric Pilmore
  Cc: linux-pci, dmaengine, Joerg Roedel, Will Deacon, iommu,
	linux-kernel

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-10-31 11:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-10-27 19:17 IOVA address range Eric Pilmore
2023-10-30 18:19 ` Bjorn Helgaas
2023-10-31 11:46   ` Robin Murphy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox