mem-cache: Fix bug in classic cache while clflush

This change, https://github.com/gem5/gem5/pull/205, mistakenly
allocates write buffer for clflush instruction when there's a
cache miss. However, clflush in gem5 is not a write instruction.
Thus, the cache should allocate miss buffer in this case.

Change-Id: I9c1c9b841159c4420567e9c929e71e4aa27d5c28
Signed-off-by: Hoa Nguyen <hn@hnpl.org>

src/mem/cache/cache.cc

@@ -338,22 +338,27 @@ Cache::handleTimingReqMiss(PacketPtr pkt, CacheBlk *blk, Tick forward_time,
 
         if (pkt->isWrite()) {
             allocateWriteBuffer(pkt, forward_time);
-        } else if (pkt->isRead()) {
+        } else {
             // uncacheable accesses always allocate a new MSHR
 
             // Here we are using forward_time, modelling the latency of
             // a miss (outbound) just as forwardLatency, neglecting the
             // lookupLatency component.
+
+            // Here we allow allocating miss buffer for read requests
+            // and x86's clflush requests. A clflush request should be
+            // propagate through all levels of the cache system.
+
+            // Doing clflush in uncacheable regions might sound contradictory;
+            // however, it is entirely possible due to how the Linux kernel
+            // handle page property changes. When a linux kernel wants to
+            // change a page property, it flushes the related cache lines. The
+            // kernel might change the page property before flushing the cache
+            // lines. This results in the clflush might occur in an uncacheable
+            // region, where the kernel marks a region uncacheable before
+            // flushing. clflush results in a CleanInvalidReq.
+            assert(pkt->isRead() || pkt->isCleanInvalidateRequest());
             allocateMissBuffer(pkt, forward_time);
-        } else {
-            // When a linux kernel wants to change a page property,
-            // it flushes the related cache lines. The kernel might change
-            // the page property before flushing the cache. This results in
-            // the clflush might occur in an uncacheable region.
-            // clflush results in a CleanInvalidReq, which is neither read
-            // nor write.
-            assert(pkt->isCleanInvalidateRequest());
-            allocateWriteBuffer(pkt, forward_time);
         }
 
         return;