linux-kernel - Re: [RFC] MMIO accessors & barriers documentation

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: <1157968778.3879.41.camel@localhost.localdomain>
Date:	Mon, 11 Sep 2006 19:59:37 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"David S. Miller" <davem@...emloft.net>,
	Jeff Garzik <jgarzik@...ox.com>,
	Paul Mackerras <paulus@...ba.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>,
	Segher Boessenkool <segher@...nel.crashing.org>
Subject: Re: [RFC] MMIO accessors & barriers documentation

> I'd rather memcpy_to/from_io only made guarantees about the start/end of
> the transfer and not order of read/writes or size of read/writes. The
> reason being that a more restrictive sequence can be efficiently
> expressed using read/writefoo but the reverse is not true.

Ok, so we would define ordering on the first and last accesses (being
the first and last in ascending addresses order) and leave it free to
the implementation to do what it wants in between. Is that ok ?

> > > "Except where the underlying device is marked as cachable or
> > > prefetchable"
> > 
> > You aren't supposed to use MMIO accessors on cacheable memory, are you ?
> 
> Why not. Providing it is in MMIO space, consider ROMs for example or
> write path consider frame buffers.

If we consider cacheable accesses, we need to also provide cache
flushing primitives as MMIO devices are generally not coherent. Take for
example the case of the frame buffer: you may want to upload a texture,
and later use it with the engine. You need a way in between to make sure
all the cached dirty lines have been pushed to the device before you
start the engine. Since we provide no generically useable functions for
doing such cache coherency on MMIO space, I'd rather keep usage of MMIO
accessors on cacheable storage non-defined. That is add a simple note at
the top of the file that the rules defined here only apply to
non-cacheable mappings. Is that ok ?

> > with cacheable mappings of anything behind HT... I'd keep use of
> > cacheable mapping as an arch specific special case for now, and that
> > definitely doesn't allow for MMIO accessors ...
> 
> I'm describing existing semantics 8)

Well, there is no clear existing semantics, at least not global to all
archs for cacheable access to MMIO so yeah, let's say that ordering on
cacheable storage is left undefined :)

Ben.

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