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  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]
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/

Powered by blists - more mailing lists