linux-kernel - Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140712093917.GD18601@arm.com>
Date:	Sat, 12 Jul 2014 10:39:17 +0100
From:	Will Deacon <will.deacon@....com>
To:	Rob Clark <robdclark@...il.com>
Cc:	Thierry Reding <thierry.reding@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <Pawel.Moll@....com>,
	Mark Rutland <Mark.Rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Arnd Bergmann <arnd@...db.de>, Joerg Roedel <joro@...tes.org>,
	Olav Haugan <ohaugan@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Grant Grundler <grundler@...omium.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Marc Zyngier <Marc.Zyngier@....com>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Varun Sethi <varun.sethi@...escale.com>,
	Cho KyongHo <pullip.cho@...sung.com>,
	Dave P Martin <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Hiroshi Doyu <hdoyu@...dia.com>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings

Hi Rob,

On Fri, Jul 11, 2014 at 09:55:14PM +0100, Rob Clark wrote:
> On Fri, Jul 4, 2014 at 11:29 AM, Thierry Reding
> <thierry.reding@...il.com> wrote:
> > From: Thierry Reding <treding@...dia.com>
> ok, so I was working through this to try to convert my
> {qcom,msm}-iommu-v0 RFC over to using these bindings.  For background,
> I was initially using something that looked a bit more like the
> current arm-smmu bindings:
> 
>         gpu {
>             #stream-id-cells = <16>;
>             ...
>         };
> 
>         gfx3d: qcom,iommu@...0000 {
>             compatible = "qcom,iommu-v0";
>             ...
>             mmu-masters =
>                 /* gfx3d_user: */
>                 <&gpu 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15>,
>                 /* gfx3d_priv: */
>                 <&gpu 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31>;
>         };
> 
>         gfx3d1: qcom,iommu@...0000 {
>             compatible = "qcom,iommu-v0";
>             ...
>             mmu-masters =
>                 /* gfx3d_user: */
>                 <&gpu 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15>,
>                 /* gfx3d_priv: */
>                 <&gpu 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31>;
>         };
> 
> With my current arrangement, I have everything I need when the iommu
> device is probed to set up each of the context banks
> 
> This proposal inverts that relationship.  Which forces me to do a lot
> more (including DT parsing) on device attach.  Which I'm not a huge
> fan of.  Ie. if I even wanted to try to implement per-process
> pagetables for gpu without completely going behind the IOMMU API's
> back, I would want attach/detach to be as lightweight as possible.

I think we'd have to walk the entire device-tree at IOMMU probe time in
order to enumerate the masters, which sounds horrible... If we want to do
clever SMR allocation on the ARM SMMU (as I've been discussing with Olav),
we're going to need knowledge about *all* the valid Stream IDs in the system
before we can program *any* translations.

> Was there actually a good reason for having the device link to the
> iommu rather than the other way around?  How much would people hate it
> if I just ignore the generic bindings and use something that works for
> me instead.  I mean, it isn't exactly like there is going to be .dts
> re-use across different SoC's..  and at least with current IOMMU API
> some sort of of_get_named_iommu() API doesn't really make sense.

The thing is, if you end up ignoring the generic binding then we have two
IOMMUs using the same (ARM SMMU) binding and it begs the question as to
which is the more generic! I know we're keen to get this merged, but merging
something that people won't use and calling it generic doesn't seem ideal
either. We do, however, desperately need a generic binding.

Turning the question around; Thierry -- what are the issue in using
something like the ARM SMMU binding (master device IDs held in the IOMMU
node) for the nvidia IOMMU?

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/