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]

Message-ID: <20140625095735.GI6153@arm.com>
Date:	Wed, 25 Jun 2014 10:57:36 +0100
From:	Will Deacon <will.deacon@....com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Olav Haugan <ohaugan@...eaurora.org>,
	Rob Herring <robherring2@...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>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Grant Grundler <grundler@...omium.org>,
	Joerg Roedel <joro@...tes.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>,
	Thierry Reding <thierry.reding@...il.com>,
	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>,
	Hiroshi Doyu <hdoyu@...dia.com>
Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

On Wed, Jun 25, 2014 at 10:48:31AM +0100, Arnd Bergmann wrote:
> On Wednesday 25 June 2014 10:38:25 Will Deacon wrote:
> > On Wed, Jun 25, 2014 at 10:27:50AM +0100, Arnd Bergmann wrote:
> > > I think the situation is a bit different here: It's less about the corner
> > > cases for the SMMU, but about the question whether it makes more sense to
> > > have the kernel figure out the settings, or have them come from DT
> > > all the time.
> > 
> > But, as far as I can tell, this setting is basically `which bits are
> > constant among this set of IDs'.
> > 
> > > As I said, I can't tell which approach is best here, but it sounds to
> > > me we should either do dynamic configuration and get it right, or
> > > hardcode the configuration it all the time if we can't.
> > 
> > I disagree. If you have `sensible' StreamID allocations, doing this
> > dynamically should be straight-forward and gives the driver more flexibility
> > (e.g. we then have the option of combining SMR entries for different masters
> > if they are in the same domain). The dynamic approach also lends itself to
> > sanity-checking (it is IMPLEMENTATION DEFINED whether the SMMU detects SMR
> > aliases) and helps with virtualisation (forcing QEMU to generate these masks
> > in a device-tree for a guest using a virtual SMMU interface is very painful).
> 
> In which case do you think hardcoding is needed then? I'm still confused
> why you think we need both, as your arguments seem to all be in favor of
> dynamic configuration.

So far, I've been avoiding the hardcoding. However, you could potentially
build a system with a small number of SMRs (compared to the number of
StreamIDs) and allocate the StreamIDs in such a way that I think the dynamic
configuration would be NP complete if we require an optimal SMR allocation.

However:

  (1) I don't know of a system where this is the case
  (2) Not much work has been done on improving the dynamic allocator yet

which is why I'm still favouring dynamic configuration in the driver.

The other thing I forgot to mention earlier is that we need to support
device hotplug in the future, so some level of dynamic configuration
will always be required.

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/