Re: [Ksummit-discuss] [TECH TOPIC] Semantics of MMIO mapping attributes accross archs

[Catalin Marinas <catalin.marinas@arm.com>]

On Sun, Jul 05, 2015 at 07:55:39PM +0100, Andy Lutomirski wrote:
> On Sat, Jul 4, 2015 at 8:02 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Sat, 2015-07-04 at 07:12 -0700, Dan Williams wrote:
> >
> >> Another side topic that has come up in this space is the desire to
> >> define a "memremap" api to clean up __iomem abuses for cases where
> >> "memory-like" mappings are needed.
> >>
> >> https://lkml.org/lkml/2015/6/22/100
> >
> > Interesting. I had missed this. There is a similar question about
> > semantics (ordering etc...), ie, are they the same as memory for
> > example ?
> >
> > Another thing we might look into is to what extent should we provide
> > access to the "SAO" mapping attribute that POWER7 and later support
> > (strong ordering, pretty-much x86 like) and whether this can be used
> > on ppc to reduce the need for barriers (that attribute is only available
> > for fully cachable mappings, not generally applicable to IO mappings).
> >
> > That translate to: should your new memremap() take some kinds of flags
> > as an argument ? Though of course providing a cross-arch definition of
> > these flags would be tricky.
> 
> At some point, it would also be nice if the various macros has
> well-defined semantics.  For example, x86 has:
> 
> #define pgprot_noncached(prot)                                          \
>         ((boot_cpu_data.x86 > 3)                                        \
>          ? (__pgprot(pgprot_val(prot) |                                 \
>                      cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS)))     \
>          : (prot))
> 
> Putting aside the pointless boot_cpu_data check (surely the recent PAT
> rework completely obsoletes it), what is
> pgprot_noncached(pgprot_writecombine(x)) supposed to do?  Currently it
> results in garbage.  Should it have well-defined behavior instead?

I never thought composing pgprot_* macros/functions is supposed to
return a combined attribute. On arm32/arm64, this construct is just
returning the outermost prot, i.e. noncached here. Even if we would want
to allow such combination, we don't have enough software PTE bits for
each prot type, so these macros simply generate the corresponding
hardware bits (on newer ARM cores, that's a 3-bit index).

FWIW, on ARM, pgprot_noncached has stronger ordering semantics than what
ioremap_nocache returns and in many (most) cases it's not the
appropriate type for ARM (e.g. video framebuffers should use
writecombine since noncached doesn't even allow unaligned accesses).

-- 
Catalin