Commit graph

5 commits

Author SHA1 Message Date
Andreas Hansson
2f5262eb67 config: Make configs/common a Python package
Continue along the same line as the recent patch that made the
Ruby-related config scripts Python packages and make also the
configs/common directory a package.

All affected config scripts are updated (hopefully).

Note that this change makes it apparent that the current organisation
and naming of the config directory and its subdirectories is rather
chaotic. We mix scripts that are directly invoked with scripts that
merely contain convenience functions. While it is not addressed in
this patch we should follow up with a re-organisation of the
config structure, and renaming of some of the packages.
2016-10-14 10:37:38 -04:00
Andreas Sandberg
f16c0a4a90 sim: Decouple draining from the SimObject hierarchy
Draining is currently done by traversing the SimObject graph and
calling drain()/drainResume() on the SimObjects. This is not ideal
when non-SimObjects (e.g., ports) need draining since this means that
SimObjects owning those objects need to be aware of this.

This changeset moves the responsibility for finding objects that need
draining from SimObjects and the Python-side of the simulator to the
DrainManager. The DrainManager now maintains a set of all objects that
need draining. To reduce the overhead in classes owning non-SimObjects
that need draining, objects inheriting from Drainable now
automatically register with the DrainManager. If such an object is
destroyed, it is automatically unregistered. This means that drain()
and drainResume() should never be called directly on a Drainable
object.

While implementing the new functionality, the DrainManager has now
been made thread safe. In practice, this means that it takes a lock
whenever it manipulates the set of Drainable objects since SimObjects
in different threads may create Drainable objects
dynamically. Similarly, the drain counter is now an atomic_uint, which
ensures that it is manipulated correctly when objects signal that they
are done draining.

A nice side effect of these changes is that it makes the drain state
changes stricter, which the simulation scripts can exploit to avoid
redundant drains.
2015-07-07 09:51:05 +01:00
Steve Reinhardt
a2c21d47a8 tests: suppress output on switcheroo tests
The output from the switcheroo tests is voluminous and
(because it includes timestamps) highly sensitive to
minor changes, leading to extremely large updates to the
reference outputs.  This patch addresses this problem
by suppressing output from the tests.  An internal
parameter can be set to enable the output.  Wiring that
up to a command-line flag (perhaps even the rudimantary
-v/-q options in m5/main.py) is left for future work.
2013-11-14 15:03:42 -08:00
Andreas Sandberg
e5dca84c3f config: Move CPU handover logic to m5.switchCpus()
CPU switching consists of the following steps:
 1. Drain the system
 2. Switch out old CPUs (cpu.switchOut())
 3. Change the system timing mode to the mode the new CPUs require
 4. Flush caches if switching to hardware virtualization
 5. Inform new CPUs of the handover (cpu.takeOverFrom())
 6. Resume the system

m5.switchCpus() previously only did step 2 & 5. Since information
about the new processors' memory system requirements is now exposed,
do all of the steps above.

This patch adds automatic memory system switching and flush (if
needed) to switchCpus(). Additionally, it adds optional draining to
switchCpus(). This has the following implications:

* changeToTiming and changeToAtomic are no longer needed, so they have
  been removed.

* changeMemoryMode is only used internally, so it is has been renamed
  to be private.

* switchCpus requires a reference to the system containing the CPUs as
  its first parameter.

WARNING: This changeset breaks compatibility with existing
configuration scripts since it changes the signature of
m5.switchCpus().
2013-02-15 17:40:08 -05:00
Andreas Sandberg
5fb00e1df6 tests: Add CPU switching tests
This changeset adds a set of tests that stress the CPU switching
code. It adds the following test configurations:

 * tsunami-switcheroo-full -- Alpha system (atomic, timing, O3)
 * realview-switcheroo-atomic -- ARM system (atomic<->atomic)
 * realview-switcheroo-timing -- ARM system (timing<->timing)
 * realview-switcheroo-o3 -- ARM system (O3<->O3)
 * realview-switcheroo-full -- ARM system (atomic, timing, O3)

Reference data is provided for the 10.linux-boot test case. All of the
tests trigger a CPU switch once per millisecond during the boot
process.

The in-order CPU model was not included in any of the tests as it does
not support CPU handover.
2013-01-07 13:05:52 -05:00