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:	Mon, 16 Jun 2014 18:04:16 +0100
From:	Will Deacon <will.deacon@....com>
To:	Stuart Yoder <stuart.yoder@...escale.com>
Cc:	Varun Sethi <Varun.Sethi@...escale.com>,
	Thierry Reding <thierry.reding@...il.com>,
	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>
Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

Hi Stuart,

On Mon, Jun 16, 2014 at 05:56:32PM +0100, Stuart Yoder wrote:
> > Do you have use-cases where you really need to change these mappings
> > dynamically?
> 
> Yes.  In the case of a PCI bus-- you may not know in advance how many
> PCI devices there are until you probe the bus.   We have another FSL
> proprietary bus we call the "fsl-mc" bus that is similar.

For that case, though, you could still describe an algorithmic
transformation from RequesterID to StreamID which corresponds to a fixed
mapping.

> Another thing to consider-- starting with SMMUv2, as you know, there
> is a new distributed architecture with multiple TBUs and a centralized
> TCU that walks the SMMU page tables.  So instead of sprinkling multiple
> SMMUs all over an SoC you now have the option a 1 central TCU and sprinkling
> multiple TBUs around.   However, this means that the stream ID namespace
> is now global and can be pretty limited.  In the SMMU implementation we 
> have there are only 64 stream ID total for our Soc.  But we have many more
> masters than that.
> 
> So we look at stream IDs as really corresponding to an 'isolation context'
> and not to a bus master.  An isolation context is the domain you are
> trying to isolate with the SMMU.  Devices that all belong to the same
> 'isolation context' can share the same stream ID, since they share
> the same domain and page tables.

Ok, this is more compelling.

> So, perhaps by default some/most SMMU masters may have a default stream ID
> of 0x0 that is used by the host...and that could be represented
> statically in the device tree.
> 
> But, we absolutely will need to dynamically set new stream IDs
> into masters when a new IOMMU 'domain' is created and devices
> are added to it.   All the devices in a domain will share
> the same stream ID.
> 
> So whatever we do, let's please have an architecture flexible enough
> to allow for this.

What is the software interface to the logic that assigns the StreamIDs? Is
it part of the SMMU, or a separate device (or set of devices)?

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/