summaryrefslogtreecommitdiff
path: root/src/cpu/BaseCPU.py
diff options
context:
space:
mode:
authorAndreas Sandberg <Andreas.Sandberg@ARM.com>2013-01-07 13:05:47 -0500
committerAndreas Sandberg <Andreas.Sandberg@ARM.com>2013-01-07 13:05:47 -0500
commit964aa49d1523787c06491453a85fad511b0a5883 (patch)
treef98a023bc20227f0a06d909df5f42053dd9218f1 /src/cpu/BaseCPU.py
parent1814a85a055732baf98fd030441bb4c5c5db9bdc (diff)
downloadgem5-964aa49d1523787c06491453a85fad511b0a5883.tar.xz
mem: Fix guest corruption when caches handle uncacheable accesses
When the classic gem5 cache sees an uncacheable memory access, it used to ignore it or silently drop the cache line in case of a write. Normally, there shouldn't be any data in the cache belonging to an uncacheable address range. However, since some architecture models don't implement cache maintenance instructions, there might be some dirty data in the cache that is discarded when this happens. The reason it has mostly worked before is because such cache lines were most likely evicted by normal memory activity before a TLB flush was requested by the OS. Previously, the cache model would invalidate cache lines when they were accessed by an uncacheable write. This changeset alters this behavior so all uncacheable memory accesses cause a cache flush with an associated writeback if necessary. This is implemented by reusing the cache flushing machinery used when draining the cache, which implies that writebacks are performed using functional accesses.
Diffstat (limited to 'src/cpu/BaseCPU.py')
0 files changed, 0 insertions, 0 deletions