>> > If we used true DMA, I'd agree. But aren't we doing pseudo DMA?
>> > Thus all data went through the CPU, so the cache should have
>> > seen Process B get paged in, as the CPU did it?
>>
>> Hmm...  You are right...  The memory would have to go through the CPU
>> to the physical addresses.  I'm not sure when it's necessary to flush
>> the cache, now...
>
>Yep, that's exactly what's been puzzling me for more than a year...
>
>> > Also, how is the cache told not to cache IO addresses?
>>
>> By bits in the page table.  There are "cache mode" bits and these are
>> set to "cache-inhibit" for the I/O space (see pmap_bootstrap.c).
>
>That's the case for the primary (on-chip) cache, right?  But, the
>secondary (external) cache on accelerators has to have a priori
>knowledge of cacheable and uncacheable space of given architecture,
>don't they?


On the 68030, the CIIN signal informs external cache weather the current
cycle is a cachable cyle according to the cache bits in the on chip mmu.
This becomes handy with DMA.  You can a priori make the hardware registers
unchacheable, but if you are doing DMA to address spaces that vary on the
fly, as verses always to the same place, then it would be nice if you could
just mark a page as uncacheable in the mmu tables, then the CIIN pins out
of the 030 inform the external (L2) cache that the current access is not a
cacheable access.

---------
Christopher R. Bowman
crb@eng.umd.edu
My home page