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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 14 Jul 2014 08:24:29 +0200
From:	Thierry Reding <>
To:	Rob Clark <>
Cc:	Arnd Bergmann <>, Will Deacon <>,
	Rob Herring <>,
	Pawel Moll <>,
	Mark Rutland <>,
	Ian Campbell <>,
	Kumar Gala <>,
	Stephen Warren <>,
	Joerg Roedel <>,
	Olav Haugan <>,
	"" <>,
	Grant Grundler <>,
	Linux Kernel Mailing List <>,
	Marc Zyngier <>,
	"" <>,
	"" <>,
	Varun Sethi <>,
	Cho KyongHo <>,
	Dave P Martin <>,
	Hiroshi Doyu <>,
	linux-arm-msm <>
Subject: Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings

On Sat, Jul 12, 2014 at 08:57:31AM -0400, Rob Clark wrote:
> On Sat, Jul 12, 2014 at 8:22 AM, Arnd Bergmann <> wrote:
> > The way that Thierry's binding does that is the obvious solution to this,
> > and it mirrors what we do in practically every other subsystem. I definitely
> > want the SMMU to change before anybody starts using it in a real system,
> > which we fortunately do not have yet.
> hmm, well if some of the things I need for (like this or batching
> mappings) are too weird and gpu specific, I'm willing to duplicate the
> IOMMU driver in drm/msm.  It really isn't so much code, and that gives
> me a lot more more flexibility to do crazy things... at some point I'm
> probably going to want to do context switches by banging the IOMMU
> registers directly from the gpu.

If the IOMMU API doesn't provide for what you need, then perhaps it's
time to enhance it? We do that all the time in other parts of the
kernel, why should IOMMU be special?

It seems to me like context switching for per-process address space
isolation is one of the important features of an IOMMU. If the current
API doesn't let you do that then we should think of ways how it can be
improved. And if it doesn't do it fast enough, then we should equally
find ways to speed it up.

This is part of why I think it would be good to have explicit objects
associated with IOMMU contexts. That would give us a good place to add
caching for this kind of situation. Currently we're required to handle
most of this in drivers (map from struct device to context, ...).


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists