Using dma-ranges with iommu to limit range of iova

Using dma-ranges with iommu to limit range of iova

[Vivek Gautam]

Hi all,

I have a question regarding usage of 'dma-ranges', can someone point me 
in the right direction?
On qcom soc, few of the master devices with iommu attached to them, have 
limitations in using the iova address range. They can allow the iova to 
be only in a certain range, e.g. video codec firmware can only access 
iova only in a first few MBs as the video's arm core reset starts at 0x0.
To do that, I earlier, had the understanding that we can modify the 
iommu_domain's geometry aperture. But that looks kind of a hacky way to 
get the domain for the device and modify the aperture.
I was trying to explore if we can use the dma-ranges property. But the 
iommu bindings documentation doesn't really talks much about usage of 
dma-ranges.
Can someone help me with with the answer to - can we use 'dma-ranges' to 
limit a device's iova address access? If yes, then how?

TIF

Regards
Vivek

Re: Using dma-ranges with iommu to limit range of iova

[Robin Murphy]

Hi Vivek,

On 05/03/18 09:06, Vivek Gautam wrote:
> Hi all,
> 
> I have a question regarding usage of 'dma-ranges', can someone point me 
> in the right direction?
> On qcom soc, few of the master devices with iommu attached to them, have 
> limitations in using the iova address range. They can allow the iova to 
> be only in a certain range, e.g. video codec firmware can only access 
> iova only in a first few MBs as the video's arm core reset starts at 0x0.
> To do that, I earlier, had the understanding that we can modify the 
> iommu_domain's geometry aperture. But that looks kind of a hacky way to 
> get the domain for the device and modify the aperture.
> I was trying to explore if we can use the dma-ranges property. But the 
> iommu bindings documentation doesn't really talks much about usage of 
> dma-ranges.
> Can someone help me with with the answer to - can we use 'dma-ranges' to 
> limit a device's iova address access? If yes, then how?

Yes, if the device has physical restrictions on what it can address, 
then "dma-ranges" is the correct way to describe that. That should be 
pretty much orthogonal to the IOMMU binding and combine in the obvious 
way, e.g.:

	...
	soc {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "simple-bus";
		ranges;

		...

		iommu@f0000000 {
			compatible = "iommu";
			reg = <0xf0000000 0x1000>;
			#iommu-cells = <0>;
		};

		...

		subsystem {
			#address-cells = <1>;
			#size-cells = <1>;
			compatible = "simple-bus";
			ranges;
			/* Devices can only drive address bits 0:23 */
			dma-ranges = <0 0 0x1000000>;

			device {
				iommus = <&iommu>;
			};
		};
	};
	...

In terms of Linux, for the straightforward platform device case 
of_dma_configure() initialises the subsystem devices' DMA masks based on 
the size covered by "dma-ranges", and the DMA API code respects the 
device's DMA mask when allocating IOVAs. The only problem is the bit in 
the middle where the device driver's dma_set_mask() call can just trash 
of_dma_configure()'s initial mask, because there's no way to 
differentiate an explicitly-specified mask from a default one. It's also 
even uglier for PCI devices since the existing "pass the host bridge's 
node as the device's" bodge happens to work for the "dma-coherent" 
property but is a bit broken in general and doesn't work at all for 
"dma-ranges".

Fixing all of this (not to mention the DT/ACPI interaction aspect) has 
been hovering around #3 on my to-do list for the past couple of years 
now, but things keep sneaking in above it :(

Robin.

Re: Using dma-ranges with iommu to limit range of iova

[Vivek Gautam]

Hi Robin,


On 3/5/2018 5:46 PM, Robin Murphy wrote:
> Hi Vivek,
>
> On 05/03/18 09:06, Vivek Gautam wrote:
>> Hi all,
>>
>> I have a question regarding usage of 'dma-ranges', can someone point 
>> me in the right direction?
>> On qcom soc, few of the master devices with iommu attached to them, 
>> have limitations in using the iova address range. They can allow the 
>> iova to be only in a certain range, e.g. video codec firmware can 
>> only access iova only in a first few MBs as the video's arm core 
>> reset starts at 0x0.
>> To do that, I earlier, had the understanding that we can modify the 
>> iommu_domain's geometry aperture. But that looks kind of a hacky way 
>> to get the domain for the device and modify the aperture.
>> I was trying to explore if we can use the dma-ranges property. But 
>> the iommu bindings documentation doesn't really talks much about 
>> usage of dma-ranges.
>> Can someone help me with with the answer to - can we use 'dma-ranges' 
>> to limit a device's iova address access? If yes, then how?
>
> Yes, if the device has physical restrictions on what it can address, 
> then "dma-ranges" is the correct way to describe that. That should be 
> pretty much orthogonal to the IOMMU binding and combine in the obvious 
> way, e.g.:
>
>     ...
>     soc {
>         #address-cells = <1>;
>         #size-cells = <1>;
>         compatible = "simple-bus";
>         ranges;
>
>         ...
>
>         iommu@f0000000 {
>             compatible = "iommu";
>             reg = <0xf0000000 0x1000>;
>             #iommu-cells = <0>;
>         };
>
>         ...
>
>         subsystem {

Usually, the multimedia devices are just the device nodes without
any subsystem. Can dma-ranges, and iommus exist together for the
device?

> #address-cells = <1>;
>             #size-cells = <1>;
>             compatible = "simple-bus";
>             ranges;
>             /* Devices can only drive address bits 0:23 */
>             dma-ranges = <0 0 0x1000000>;
>
>             device {
>                 iommus = <&iommu>;
>             };
>         };
>     };
>     ...
>
> In terms of Linux, for the straightforward platform device case 
> of_dma_configure() initialises the subsystem devices' DMA masks based 
> on the size covered by "dma-ranges", and the DMA API code respects the 
> device's DMA mask when allocating IOVAs. The only problem is the bit 
> in the middle where the device driver's dma_set_mask() call can just 
> trash of_dma_configure()'s initial mask, because there's no way to 
> differentiate an explicitly-specified mask from a default one.

But the drivers should ideally check for any existing dma_mask set for 
the device before calling dma_set_mask_and_coherent(). I see few of the 
drivers do check that, so we don't overwrite the dma mask.

> It's also even uglier for PCI devices since the existing "pass the 
> host bridge's node as the device's" bodge happens to work for the 
> "dma-coherent" property but is a bit broken in general and doesn't 
> work at all for "dma-ranges".
>
> Fixing all of this (not to mention the DT/ACPI interaction aspect) has 
> been hovering around #3 on my to-do list for the past couple of years 
> now, but things keep sneaking in above it :(

Anything that I can take a look at, and add?

regards
Vivek
>
> Robin.

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu