On Mon, May 21, 2012 at 6:20 PM, Ian Lepore
>> Some more notes.
>> SMP makes things worse and ARM11mpcore is about SMP too. For example,
>> another thread could be open about that how to flush caches (exclusive
>> L1 cache) in SMP case.
>> I'm not sure how to correctly change memory attributes on page which
>> is in use. Making new temporary mapping with different attributes is
>> wrong and does not help at all. It's question how to do TLB and cache
>> flushes on two and more processors and be sure that everything is OK.
>> It could be slow and maybe, changing memory attributes on the fly is
>> not a good idea at all.
> My suggestion of making a temporary writable mapping was the answer to
> how to correctly change memory attributes on a page which is in use, at
> least in the existing code, which is for a single processor.
> You don't need, and won't even use, the temporary mapping. You would
> make it just because doing so invokes logic in arm/arm/pmap.c which will
> find all existing virtual mappings of the given physical pages, and
> disable caching in each of those existing mappings. In effect, it makes
> all existing mappings of the physical pages DMA_COHERENT. When you
> later free the temporary mapping, all other existing mappings are
> changed back to being cacheable (as long as no more than one of the
> mappings that remain is writable).
> I don't know that making a temporary mapping just for its side effect of
> changing other existing mappings is a good idea, it's just a quick and
> easy thing to do if you want to try changing all existing mappings to
> non-cacheable. It could be that a better way would be to have the
> busdma_machdep code call directly to lower-level routines in pmap.c to
> change existing mappings without making a new temporary mapping in the
> kernel pmap. The actual changes to the existing mappings are made by
> pmap_fix_cache() but that routine isn't directly callable right now.
Thanks for explanation. In fact, I known only a little about current
ARM pmap implementation in FreeBSD tree. I took i386 pmap
implementation and modified it according to arm11mpcore.
> Also, as far as I know all of this automatic disabling of cache for
> multiple writable mappings applies only to VIVT cache architectures.
> I'm not sure how the pmap code is going to change to support VIPT and
> PIPT caches, but it may no longer be true that making a second writable
> mapping of a page will lead to changing all existing mappings to
> -- Ian