linux-kernel - Re: [Linaro-mm-sig] [RFC] ARM DMA mapping TODO, v1

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:	Fri, 29 Apr 2011 17:41:17 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linaro-mm-sig@...ts.linaro.org
Cc:	Catalin Marinas <catalin.marinas@....com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [Linaro-mm-sig] [RFC] ARM DMA mapping TODO, v1

On Wednesday 27 April 2011, Catalin Marinas wrote:
> > >
> > > It's not broken since we moved to using Normal non-cacheable memory
> > > for the coherent DMA buffers (as long as you flush the cacheable alias
> > > before using the buffer, as we already do). The ARM ARM currently says
> > > unpredictable for such situations but this is being clarified in
> > > future updates and the Normal non-cacheable vs cacheable aliases can
> > > be used (given correct cache maintenance before using the buffer).
> > 
> > Thanks for that information, I believe a number of people in the
> > previous discussions were relying on the information from the
> > documentation. Are you sure that this is not only correct for the
> > cores made by ARM ltd but also for the other implementations that
> > may have relied on documentation?
> 
> It is a clarification in the ARM ARM so it covers all the cores made by
> architecture licensees, not just ARM Ltd. It basically makes the
> "unpredictable" part more predictable to allow certain types of aliases
> (e.g. Strongly Ordered vs Normal memory would still be disallowed).
> 
> All the current implementations are safe with Normal memory aliases
> (cacheable vs non-cacheable) but of course, there may be some
> performance benefits in not having any alias.

A lot of the discussions we are about to have in Budapest will be
around solving the problem of having only valid combinations of
mappings, so we really need to have a clear statement in specification
form about what is actually valid.

Would it be possible to have an updated version of the relevant
section of the ARM ARM by next week so we can use that as the
base for our discussions?

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