linux-kernel - Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management

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:	Thu, 15 Jul 2010 20:48:36 -0400
From:	Tim HRM <zt.tmzt@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Zach Pfeffer <zpfeffer@...eaurora.org>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	ebiederm@...ssion.com, linux-arch@...r.kernel.org,
	dwalker@...eaurora.org, mel@....ul.ie,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, andi@...stfloor.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device 
	memory management

On Thu, Jul 15, 2010 at 4:55 AM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> On Wed, Jul 14, 2010 at 06:29:58PM -0700, Zach Pfeffer wrote:
>> The VCM ensures that all mappings that map a given physical buffer:
>> IOMMU mappings, CPU mappings and one-to-one device mappings all map
>> that buffer using the same (or compatible) attributes. At this point
>> the only attribute that users can pass is CACHED. In the absence of
>> CACHED all accesses go straight through to the physical memory.
>
> So what you're saying is that if I have a buffer in kernel space
> which I already have its virtual address, I can pass this to VCM and
> tell it !CACHED, and it'll setup another mapping which is not cached
> for me?
>
> You are aware that multiple V:P mappings for the same physical page
> with different attributes are being outlawed with ARMv6 and ARMv7
> due to speculative prefetching.  The cache can be searched even for
> a mapping specified as 'normal, uncached' and you can get cache hits
> because the data has been speculatively loaded through a separate
> cached mapping of the same physical page.
>
> FYI, during the next merge window, I will be pushing a patch which makes
> ioremap() of system RAM fail, which should be the last core code creator
> of mappings with different memory types.  This behaviour has been outlawed
> (as unpredictable) in the architecture specification and does cause
> problems on some CPUs.
>
> We've also the issue of multiple mappings with differing cache attributes
> which needs addressing too...
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Interesting, since I seem to remember the MSM devices mostly conduct
IO through regions of normal RAM, largely accomplished through
ioremap() calls.

Without more public domain documentation of the MSM chips and AMSS
interfaces I wouldn't know how to avoid this, but I can imagine it
creates a bit of urgency for Qualcomm developers as they attempt to
upstream support for this most interesting SoC.

--
Timothy Meade
tmzt #htc-linux
--
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/