----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2717/#review6005 -----------------------------------------------------------
src/cpu/o3/cpu.cc <http://reviews.gem5.org/r/2717/#comment5223> might want to update comment to say "cacheable block" src/dev/dma_device.cc <http://reviews.gem5.org/r/2717/#comment5224> same here src/mem/cache/cache_impl.hh <http://reviews.gem5.org/r/2717/#comment5226> is this really necessary? I'm curious why setting this flag actually breaks things src/mem/cache/cache_impl.hh <http://reviews.gem5.org/r/2717/#comment5225> create a helper function for this loop, since it also appears below now? or maybe we should convert AddrRangeList to a class, and add this as a method... src/mem/cache/mshr.cc <http://reviews.gem5.org/r/2717/#comment5227> same comment as above src/mem/cache/mshr.cc <http://reviews.gem5.org/r/2717/#comment5228> why not: if (!pkt->needsExclusive() && !pkt->req->isUncacheable()) { - Steve Reinhardt On March 30, 2015, 2:17 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2717/ > ----------------------------------------------------------- > > (Updated March 30, 2015, 2:17 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10783:84330bcae3c6 > --------------------------- > mem: Snoop into caches on uncacheable accesses > > This patch takes a last step in fixing issues related to uncacheable > accesses. We do not separate uncacheable memory from uncacheable > devices, and in cases where it is really memory, there are valid > scenarios where we need to snoop since we do not support cache > maintenance instructions (yet). On snooping an uncacheable access we > thus provide data if possible. In essence this makes uncacheable > accesses IO coherent. > > The snoop filter is also queried to steer the snoops, but not updated > since the uncacheable accesses do not allocate a block. > > At the moment there are quite a few special cases where we > need to check to ensure uncacheable accesses do not steal exclusivity > etc, and perhaps there is a nicer way to embed these checks in the > existing packet methods. > > > Diffs > ----- > > src/mem/cache/mshr.cc 8a7285d6197e > src/mem/coherent_xbar.cc 8a7285d6197e > src/mem/snoop_filter.cc 8a7285d6197e > src/cpu/o3/cpu.cc 8a7285d6197e > src/dev/dma_device.cc 8a7285d6197e > src/mem/cache/cache_impl.hh 8a7285d6197e > > Diff: http://reviews.gem5.org/r/2717/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
