Message-ID: <496c2d88-2558-42fe-8434-81c000955a84@arm.com>
Date: Thu, 9 Oct 2025 13:16:10 +0100
From: Robin Murphy <robin.murphy@....com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Rob Herring <robh@...nel.org>,
 Charan Teja Kalla <charan.kalla@....qualcomm.com>
Cc: joro@...tes.org, will@...nel.org, saravanak@...gle.com,
 conor+dt@...nel.org, mchehab@...nel.org, bod@...nel.org, krzk+dt@...nel.org,
 abhinav.kumar@...ux.dev, vikash.garodia@....qualcomm.com,
 dikshita.agarwal@....qualcomm.com, linux-media@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, iommu@...ts.linux.dev
Subject: Re: [RFC PATCH 0/3] Introduce iommu-map-masked for platform devices

On 2025-10-09 1:26 am, Krzysztof Kozlowski wrote:
> On 29/09/2025 05:23, Rob Herring wrote:
>> On Sun, Sep 28, 2025 at 12:17 PM Charan Teja Kalla
>> <charan.kalla@....qualcomm.com> wrote:
>>>
>>> This series introduces a new iommu property called iommu-map-masked(may
>>> be there is a better name), which is used to represent the IOMMU
>>> specifier pairs for each function of a __multi-functional platform
>>> device__, where each function can emit unique master id(s) that can be
>>> associated with individual translation context.
>>>
>>> Currently, the iommu configuration - at least for arm architecture-
>>> requires all the functions of a platform device will be represented
>>> under single dt node thus endup in using only a single translation
>>> context.
>>>
>>> A simple solution to associate individual translation context for each
>>> function of a device can be through creating per function child nodes in
>>> the device tree, but dt is only to just represent the soc layout to
>>> linux kernel.
>>>
>>> Supporting such cases requires a new iommu property called,
>>> iommu-map-masked(taking cue from iommu-map for pci devices) and syntax
>>> is:
>>>     iommu-map-masked = <FUNCTION_ID1 &iommu ID1 MASK1>,
>>>                        <FUNCTION_ID2 &iommu ID2 MASK2>;
>>> NOTE: As an RFC, it is considered that this property always expects 4
>>> cells.
>>>
>>> During the probe phase of the driver for a multi-functional device
>>> behind an IOMMU, a child device is instantiated for each FUNCTION_ID.
>>> The call to of_dma_configure_id() on each child sets up the IOMMU
>>> configuration, ensuring that each function of the device is associated
>>> with a distinct translation context.
>>>
>>> This property can also be used in association with 'iommus=' when dt
>>> bindings requires the presence of 'iommus=', example[2]. For these
>>> cases, representation will be(on arm64):
>>>     iommus = <&iommu sid mask>; //for default function.
>>>     iommu-map-masked = <FUNCTION_ID &iommu sid mask>;//additional
>>> function.
>>
>> Where does the FUNCTION_ID value come from?
>>
>> Why can't you just have multiple "iommus" entries where the index
>> defines the default and any FUNCTION_ID entries? What's in each index
>> is specific to the device.
> 
> 
> We discussed the problem earlier and that is what I asked them to do.
> Apparently I was just ignored so now two maintainers say the same. We
> can get ignored still and the third maintainer will have to tell this.

The reason why that isn't really viable is that the "iommus" property 
needs to be consumed directly by the relevant IOMMU driver(s) without a 
dependency on any driver for the client device represented by the node 
itself. For security/isolation purposes the IOMMU has to know about all 
potential DMA sources and be able to be configured for them *before* 
anyone else gets a chance to start initiating DMA from them. If the DT 
consumer is, say, a bare-metal hypervisor, it may have no understanding 
whatsoever of what most of the client devices are nor how they work.

This is part of the reason why we went for a separate "iommu-map" 
property for buses, so that an IOMMU consumer *can* easily tell when 
multiple specifiers do not represent an indivisible set tied to the 
given device, and thus it can expect help from a bus driver to subdivide 
them later (but in the meantime can still safely isolate the entire bus 
based on the output of the map without having to understand the inputs.)

Now, I suppose in some cases it might be technically possible for a 
client device driver to collude with an IOMMU driver to divide a 
monolithic DT device into logical functions after the fact, but for 
Linux I don't see an acceptable way of doing that without some major 
changes to the driver model abstraction and IOMMU API...

Thanks,
Robin.

Powered by blists - more mailing lists