cpu: Delegate comInstEventQueue methods to the ThreadContexts.

These then just use the comInstEventQueue array from the CPU, but soon
they will actually be self contained and allow the thread context to
use whatever mechanism it wants.

Also, now that the thread contexts need to exist before instruction
count based events can be scheduled, setting up max instruction based
events needs to happen in init after the CPU subclasses have had a
chance to set up the threadContexts vector.

Change-Id: I34bb401633d277a60be74e30d5a478a149b972ea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22108
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>

1 files changed, 6 insertions, 0 deletions

diff --git a/src/cpu/thread_context.hh b/src/cpu/thread_context.hh
index 749b4ca90..a6793a263 100644
--- a/src/cpu/thread_context.hh
+++ b/src/cpu/thread_context.hh
@@ -192,6 +192,12 @@ class ThreadContext : public PCEventScope
 
     virtual EndQuiesceEvent *getQuiesceEvent() = 0;
 
+    virtual Tick nextInstEventCount();
+    virtual void serviceInstCountEvents(Tick count);
+    virtual void scheduleInstCountEvent(Event *event, Tick count);
+    virtual void descheduleInstCountEvent(Event *event);
+    virtual Tick getCurrentInstCount();
+
     // Not necessarily the best location for these...
     // Having an extra function just to read these is obnoxious
     virtual Tick readLastActivate() = 0;