linux-kernel - Re: [RFC PATCH 0/3] Introduce iommu-map-masked for platform devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <yoqrve424xt54wbuntcrksh5nwzekntwqgbu4rzy6v4ekwzjej@mpopdkmzjrd4>
Date: Sat, 11 Oct 2025 03:54:57 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Rob Herring <robh@...nel.org>
Cc: Charan Teja Kalla <charan.kalla@....qualcomm.com>,
        Robin Murphy <robin.murphy@....com>, 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,
        Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        bjorn.andersson@....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 Fri, Oct 10, 2025 at 05:30:11PM -0500, Rob Herring wrote:
> On Fri, Oct 10, 2025 at 2:53 PM Charan Teja Kalla
> <charan.kalla@....qualcomm.com> wrote:
> > On 10/9/2025 11:55 PM, Dmitry Baryshkov wrote:
> > >>> I really don't like the idea of extending the #iommu-cells. The ARM SMMU
> > >>> has only one cell, which is correct even for our platforms. The fact
> > >>> that we need to identify different IOMMU SIDs (and handle them in a
> > >>> differnt ways) is internal to the video device (and several other
> > >>> devices). There is nothing to be handled on the ARM SMMU side.
> > >> Huh? So if you prefer not to change anything, are you suggesting this series
> > >> doesn't need to exist at all? Now I'm thoroughly confused...
> > > Hmm. We need changes, but I don't feel like adding the FUNCTION_ID to
> > > #iommu-cells is the best idea.
> > >
> > >> If you want to use SMR masks, then you absolutely need #iommu-cells = 2,
> > >> because that is the SMMU binding for using SMR masks. It would definitely
> > > I'm sorry. Yes, we have #iommu-cells = <2>.
> > >
> > >> not be OK to have some magic property trying to smuggle
> > >> IOMMU-driver-specific data contrary to what the IOMMU node itself says. As
> > >> for iommu-map, I don't see what would be objectionable about improving the
> > >> parsing to respect a real #iommu-cells value rather than hard-coding an
> > >> assumption. Yes, we'd probably need to forbid entries with length > 1
> > >> targeting IOMMUs with #iommu-cells > 1, since the notion of a linear
> > > This will break e.g. PCIe on Qualcomm platforms:
> > >
> > >                         iommu-map = <0x0   &apps_smmu 0x1400 0x1>,
> > >                                     <0x100 &apps_smmu 0x1401 0x1>;
> > >
> > >
> > > But this seems unlogical anyway wrt. apps_smmu having #iommu-cells =
> > > <2>. It depends on ARM SMMU ignoring the second cell when it's not
> > > present.
> > >
> > >> relationship between the input ID and the output specifier falls apart when
> > >> the specifier is complex, but that seems simple enough to implement and
> > >> document (even if it's too fiddly to describe in the schema itself), and
> > >> still certainly no worse than having another property that *is* just
> > >> iommu-map with implicit length = 1.
> > >>
> > >> And if you want individual StreamIDs for logical functions to be attachable
> > >> to distinct contexts then those functions absolutely must be visible to the
> > >> IOMMU layer and the SMMU driver as independent devices with their own unique
> > >> properties, which means either they come that way from the DT as of_platform
> > >> devices in the first place, or you implement a full bus_type abstraction
> >
> > I don't want to dilute what Dmitry is saying here, but the below is what
> > i can make out of Robin comments, please CMIW:
> >
> > iommu {
> >         #iommu-cells = <2>;
> > }
> >
> > video {
> >    iommu = <iommu sid1 mask1>, <iommu sid2 mask2>;
> >    #iommu-map-cells = 2; /* does it look weird to define here, even if
> > it is SMMU property? */
> 
> No, not weird. interrupt-map similarly requires #interrupt-cells. So
> it would be just #iommu-cells here.

The major problem is that our DTs already use the currently-defined
single-cell iommu-maps. I'm not sure if it is possible to support
old and new semantics. So #iommu-map-cells (but placed into the IOMMU
device) might be a good way: by default iommu-map parsing code will try
parsing just a SID, but with #iommu-map-cells it will use specified
number of arguments. The only question is what if #iommu-map-cells !=
#iommu-cells.

> 
> >    iommu-map = <0 smmu sid3 mask3>,
> >                <0 smmu sid4 mask4>;
> 
> But you only have 1 cell, not 2 here. The #iommu-cells in this node
> would define the number of cells before 'smmu'. The #iommu-cells in
> the &smmu node is the number of cells after the &smmu phandle.

-- 
With best wishes
Dmitry