X86,TLB: Make sure the "delayedResponse" variable is always set.
authorGabe Black <gblack@eecs.umich.edu>
Mon, 5 Sep 2011 09:48:57 +0000 (02:48 -0700)
committerGabe Black <gblack@eecs.umich.edu>
Mon, 5 Sep 2011 09:48:57 +0000 (02:48 -0700)
When an instruction is translated in the x86 TLB, a variable called
delayedResponse is passed back and forth which tracks whether a translation
could be completed immediately, or if there's going to be callback that will
finish things up. If a read was to the internal memory space, memory mapped
registers used to implement things like MSRs, the function hadn't yet gotten
to where delayedResponse was set to false, it's default. That meant that the
value was never set, and the TLB could start waiting for a callback that would
never come. This change simply moves the assignment to above where control
can divert to translateInt().

src/arch/x86/tlb.cc

index d2cd5eaee2ddc2adeb25f0c2ed0ffd6675f7a74d..9ba20f8d7aa39c99487dc1a78a6148d3817d4251 100644 (file)
@@ -539,13 +539,14 @@ TLB::translate(RequestPtr req, ThreadContext *tc, Translation *translation,
     int seg = flags & SegmentFlagMask;
     bool storeCheck = flags & (StoreCheck << FlagShift);
 
+    delayedResponse = false;
+
     // If this is true, we're dealing with a request to a non-memory address
     // space.
     if (seg == SEGMENT_REG_MS) {
         return translateInt(req, tc);
     }
 
-    delayedResponse = false;
     Addr vaddr = req->getVaddr();
     DPRINTF(TLB, "Translating vaddr %#x.\n", vaddr);