linux-kernel - RE: [PATCH v2] 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]

Date:	Thu, 5 Jun 2014 19:10:19 +0000
From:	Varun Sethi <Varun.Sethi@...escale.com>
To:	Will Deacon <will.deacon@....com>,
	Thierry Reding <thierry.reding@...il.com>
CC:	Mark Rutland <Mark.Rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	Pawel Moll <Pawel.Moll@....com>,
	"Arnd Bergmann" <arnd@...db.de>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	"Grant Grundler" <grundler@...omium.org>,
	Stephen Warren <swarren@...dotorg.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Linux IOMMU <iommu@...ts.linux-foundation.org>,
	"Rob Herring" <robh+dt@...nel.org>,
	Kumar Gala <galak@...eaurora.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Cho KyongHo <pullip.cho@...sung.com>,
	Dave P Martin <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Stuart Yoder <stuart.yoder@...escale.com>
Subject: RE: [PATCH v2] devicetree: Add generic IOMMU device tree bindings



> -----Original Message-----
> From: iommu-bounces@...ts.linux-foundation.org [mailto:iommu-
> bounces@...ts.linux-foundation.org] On Behalf Of Will Deacon
> Sent: Wednesday, June 04, 2014 10:12 PM
> To: Thierry Reding
> Cc: Mark Rutland; devicetree@...r.kernel.org; linux-samsung-
> soc@...r.kernel.org; Pawel Moll; Arnd Bergmann; Ian Campbell; Grant
> Grundler; Stephen Warren; linux-kernel@...r.kernel.org; Marc Zyngier;
> Linux IOMMU; Rob Herring; Kumar Gala; linux-tegra@...r.kernel.org; Cho
> KyongHo; Dave P Martin; linux-arm-kernel@...ts.infradead.org
> Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree
> bindings
> 
> On Wed, Jun 04, 2014 at 03:35:10PM +0100, Thierry Reding wrote:
> > On Mon, Jun 02, 2014 at 11:41:04AM +0100, Dave Martin wrote:
> > > In the strictest sense, no.
> > >
> > > But for a large set of sane configurations, this probably works.
> > >
> > > Small sets of randomly-assigned IDs can just be enumerated one by
> one.
> > >
> > > We wouldn't be able to describe folding and bit shuffling, but we
> > > probably don't want to encourage that anyway.
> >
> > I'm having some difficulty understanding this. You make it sound like
> > there's a fairly arbitrary number of IDs that the SMMU can handle. So
> > how is the mapping to devices defined? If you say encourage that does
> > make it sound like the assignment of IDs is purely defined by some
> > mechanism in software rather than in hardware. Or they are more or
> > less randomly picked by someone. If that's the case, is that not
> > something that should be dynamically allocated by the kernel rather
> > than put into the device tree?
> 
> The set of StreamIDs that can be generated by a master is fixed in the
> hardware. The SMMU can then be programmed to map these incoming IDs onto
> a context ID (or a set of context IDs), which are the IDs used internally
> by the SMMU to find the page tables etc.
> 
> The StreamID -> ContextID mapping is dynamic and controlled by software.
> The Master -> StreamIDs mapping is fixed in the hardware.
The Master -> StreamIDs mapping may not always be fixed in the hardware. At, least in our case we plan to program these via software. PCI devices is one place where this mapping would have to be dynamic (based on the topology i.e. if the devices are connected to a bridge etc). Also, we have a hot plug device architecture where the stream ID is software programmable.

Other than that, based on the isolation requirements (iommu domain) software programmability offers greater flexibility.

-Varun


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