coherent vs non-coherent memory access

[ggodw000]

i have an understanding of cache coherence and its associated protocol, but came across the definition of coherent vs. non-coherent request.
coherent request: memory data/code reads, write back etc.,
non-coherent request: MMIO, IORW, interrupts etc.,

I started to wonder what are the generic characterization of coherent vs. non-coherent requests. How are they related to cache coherence. Googling for sometime did not find anything that makes much sense. Does non-coherent access mean, it is prevented/not allowed from being cached?

Thanks.,

[Combuster]

Coherent means that any point in time, you can look at a piece of data and the result is exactly the same in all ways you can observe it. Caches amongst several CPU cores are coherent so if one CPU writes a piece of RAM, the other CPU is guaranteed to see that piece of memory change as well, because the CPU communicate those changes directly to each other.

Lack of coherency means that a different value may be observed elsewhere. If you would try and use caching on anything that's not system RAM, the hardware in charge might decide to change something and the old value is stale, or you try to change something and the cache doesn't put it through to the hardware for speed reasons. In both cases, two separate components observe different values. The situation often doesn't last long, but you will have to apply algorithms accordingly.

TLBs are famous for being incoherent.
Video RAM is often not coherent; the GPU can easily change pixels without being able to let the CPU know. The CPU can modify pixels in the cache and not see them on screen because it hasn't reached Video RAM yet. You can even see a form of this in QEMU with the CLI; HLT; glitch that tends to catch newcomers off-guard.
Interrupts are indeed non-coherent: in practice the interrupt cause might disappear before or while it is being handled - the interrupt controller is built on a state machine that can't handle these cases.

Port access, or uncacheable access to MMIO usually leaves no room for coherency issues because these are serialized. If you do make and use a copy of that value, then you have a cache, which might soon grow stale as the hardware keeps doing other things. Typically, this is why coherency most often only makes sense when there are copies of data - in the broadest sense.

[ggodw000]

aah, makes much more sense now. thanks!

i can deduce from here, non-coherent regions should be set as uncacheable by system firmware, otherwise, there is a chance of stale data exist. For physical RAMs, we know hardware mechanism always supports cache coherency or at least should.