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: <20140709181048.GX9485@arm.com>
Date:	Wed, 9 Jul 2014 19:10:48 +0100
From:	Will Deacon <will.deacon@....com>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	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>,
	Cho KyongHo <pullip.cho@...sung.com>,
	Grant Grundler <grundler@...omium.org>,
	Dave P Martin <Dave.Martin@....com>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Hiroshi Doyu <hdoyu@...dia.com>,
	Olav Haugan <ohaugan@...eaurora.org>,
	Varun Sethi <varun.sethi@...escale.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings

Hi Thierry,

On Wed, Jul 09, 2014 at 03:21:27PM +0100, Thierry Reding wrote:
> On Wed, Jul 09, 2014 at 02:40:50PM +0100, Will Deacon wrote:
> > I would like to move the ARM SMMU driver over to this for 3.18, if possible.
> > One use-case there is the ability to describe groups of masters behind a
> > multi-master IOMMU but which must be part of the same domain (i.e. an
> > iommu_group). This is useful for presenting devices to a guest with a
> > virtual SMMU, where the physical devices share a stage-2 context.
> > 
> > With your binding, does this simply mean determining the set of master IDs
> > in the group, then describing the complete set for each master?
> 
> I'm not sure I properly understand what you're trying to do, but I don't
> think the binding is designed to cover that. Rather the goal was to
> describe the IDs belonging to each master, so that an IOMMU can be
> properly configured.

This is directly related to that problem, see below.

> Anything beyond that (e.g. logical grouping of masters) isn't directly
> within the scope of the binding (it doesn't describe hardware but some
> policy pertaining to some specific use-case).

This *is* for hardware. I can use PCI as an example, but this could equally
apply to other types of bus. If you have a bunch of PCI master devices
sitting being a non-transparent bridge, they can end up sharing the same
master device ID (requester ID). This means that there is no way in the
IOMMU to initialise a translation for one of these devices without also
affecting the others. We currently have iommu_groups to deal with this, but
it *is* a property of the hardware and we absolutely need a way to describe
it. I'm happy to add it later, but we need to think about it now to avoid
merging something that can't easily be extended.

For PCI, the topology is probable but even then, we need this information to
describe the resulting master device ID emitted by the bridge for the
upstream group. One way to do this with your binding would be to treat all
of the upstream masters as having the same device ID.

With virtualisation, we may want to assign a group of devices to a guest but
without emulating the bridge. This would need something the device-tree to
describe that they are grouped together.

> That said, the IOMMU driver that I prototyped for Tegra did some similar
> grouping of devices, although in a much more restricted way. The goal of
> that was to add a known set of devices into one group, "peripherals", so
> that they could share one IOMMU domain. This was meant to separate them
> from devices with more advanced needs (such as a GPU driver). Devices in
> the "peripherals" group would be using the DMA mapping API integration
> whereas other devices would have to explicitly allocate an IOMMU domain.
> 
> I'm not sure how much that helps for the use-case that you have in mind.

That sounds more like a software decision, which I agree doesn't need to be
described.

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/