Several large changes happen in this patch.
The FDEntry class is rewritten so that file descriptors now correspond to
types: 'File' which is normal file-backed file with the file open on the
host machine, 'Pipe' which is a pipe that has been opened on the host machine,
and 'Device' which does not have an open file on the host yet acts as a pseudo
device with which to issue ioctls. Other types which might be added in the
future are directory entries and sockets (off the top of my head).
The FDArray class was create to hold most of the file descriptor handling
that was stuffed into the Process class. It uses shared pointers and
the std::array type to hold the FDEntries mentioned above.
The changes to these two classes needed to be propagated out to the rest
of the code so there were quite a few changes for that. Also, comments were
added where I thought they were needed to help others and extend our
DOxygen coverage.
Moves aux_vector into its own .hh and .cc files just to get it out of the
already crowded Process files. Arguably, it could stay there, but it's
probably better just to move it and give it files.
The changeset looks ugly around the Process header file, but the goal here is
to move methods and members around so that they're not defined randomly
throughout the entire header file. I expect this is likely one of the reasons
why I several unused variables related to this class. So, the methods are
declared first followed by members. I've tried to aggregate them together
so that similar entries reside near one another.
There are other changes coming to this code so this is by no means the
final product.
The numCpus method is misleading in that it's not really a measure of
how many CPUs might be executing a process, but how many thread contexts
are assigned to the process at any given point in time.
It's nice to highlight this distinction because thread contexts are never
reused in the same way that a CPU can be reused for multiple processes.
The reason that there is no reuse is that there is no CPU scheduler for SE.
The tru64 code intends to use this method and the accompanying contextIDs
field to support SMT and track the number of threads with some system calls.
With the up coming clone and exec patches, this paradigm must change. There
needs to be a 1:1 mapping between the thread contexts and processes so that
the process state between threads is allowed to vary when needed by Linux.
This should not break SMT for tru64 if the Process class is refactored so that
multiple Processes can share state between themselves. The following patches
will do the refactoring incrementally as features are added.
It looks like tru64 has some nxm* system calls, but the two fields that
are defined in the Process class are unused by any of the code. There doesn't
appear to be any reference in the tru64 code.
The EIOProcess class was removed recently and it was the only other class
which derived from Process. Since every Process invocation is also a
LiveProcess invocation, it makes sense to simplify the organization by
combining the fields from LiveProcess into Process.
Turns out that SPARC SE mode relied on M5_pid being "0" in
all cases. The entries in the SPARC TLBs are accessed with
M5_pid as their context. This is buggy in the sense that it
will never work with more than one process or any
initialization that doesn't have the M5_pid value passed in
as "0".
cd7f3a1dbf55 broke the SPARC build because it deletes M5_pid
and uses a _pid with a default of "100" instead. This caused
the SPARC TLB to never return any valid lookups for any
request; the program never moved past the first instruction
with SPARC SE in the regression tester.
The solution proposed in this changeset is to initialize
the address space identification register with the PID value
that is passed into the process class as a parameter from
Python. This should return the correct responses from the TLB
since the insertions and lookups into the page table will be
using the same PID.
Furthermore, there are corner cases in the code which elevate
privileges and revert to using context "0" as the context in
the TLB. I believe that these are related to kernel level
traps and hypervisor privilege escalations, but I'm not
completely sure. I've tried to address the corner cases
properly, but it would be beneficial to have someone who is
familiar with the SPARC architecture to take a look at this
fix.
Signed-off-by: Pierre-Yves Péneau <pierre-yves.peneau@lirmm.fr>
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed at http://reviews.gem5.org/r/3802/
Signed-off-by: Pierre-Yves Péneau <pierre-yves.peneau@lirmm.fr>
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed at http://reviews.gem5.org/r/3801/
Assertion in the respondEvent erroneously fired.
The assertion verifies that the controller has not moved to a low-power
state prior to receiving read data from the memory.
The original assertion triggered if the state was not:
PWR_IDLE or PWR_ACT.
In the case that failed, a periodic refresh event occurred around the
read. The REF is stalled until the final read burst is issued
and the subsequent PRE closes the bank. While the PRE will temporarily
move the state to PWR_IDLE, state will immediately transition to PWR_REF
due to the pending refresh operation. This state does not match the
assertion, which is subsequently triggered.
Fixed the assertion by explicitly checking that the state is not a low
power state
!PWR_SREF && !PWR_PRE_PDN && !PWR_ACT_PDN
Change-Id: I82921a733bbeac2bcb5a487c2f981448d41ed50b
Reviewed-by: Radhika Jagtap <radhika.jagtap@arm.com>
This patch extends the example big.LITTLE configuration to enable
dist-gem5 simulations of big.LITTLE systems.
Change-Id: I49c095ab3c737b6a082f7c6f15f514c269217756
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
This patch prevents the body of the script getting executed when
the script is imported as a module.
Change-Id: I70a50f6295f1e7a088398017f5fa9d06fe90476a
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
This patch prepares future extensions and customisation of the example
big.LITTLE configuration script. It breaks out the major phases into
functions so they can be called from other python scripts.
Change-Id: I2cb7c207c410fe14602cf17af7482719abba6c24
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
KvmGic functionality has been subsumed within the new MuxingKvmGic
model, which has Pl390 fallback when not using KVM for fast emulation.
This simplifies configuration and will enable checkpointing between
KVM emulation and full-system simulation.
Change-Id: Ie61251720064c512843015c075e4ac419a4081e8
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Automatically use the MuxingKvmGic in the VExpress_GEM5_V1
platform. This removes the need to patch the host kernel or the
platform configuration when using KVM on ARM.
Change-Id: Ib1ed9b3b849b80c449ef1b62b83748f3f54ada26
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
This device allows us to, when KVM support is detected and compiled in,
instantiate the same Gic device whether the actual simulation is with
KVM cores or simulated cores. Checkpointing is not yet supported.
Change-Id: I67e4e0b6fb7ab5058e52c933f4f3d8e7ab24981e
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
A KVM VM is typically a child of the System object already, but for
solving future issues with configuration graph resolution, the most
logical way to keep track of this object is for it to be an actual
parameter of the System object.
Change-Id: I965ded22203ff8667db9ca02de0042ff1c772220
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Names of DRAM configurations were updated to reflect both
the channel and device data width.
Previous naming format was:
<DEVICE_TYPE>_<DATA_RATE>_<CHANNEL_WIDTH>
The following nomenclature is now used:
<DEVICE_TYPE>_<DATA_RATE>_<n>x<w>
where n = The number of devices per rank on the channel
x = Device width
Total channel width can be calculated by n*w
Example:
A 64-bit DDR4, 2400 channel consisting of 4-bit devices:
n = 16
w = 4
The resulting configuration name is:
DDR4_2400_16x4
Updated scripts to match new naming convention.
Added unique configurations for DDR4 for:
1) 16x4
2) 8x8
3) 4x16
Change-Id: Ibd7f763b7248835c624309143cb9fc29d56a69d1
Reviewed-by: Radhika Jagtap <radhika.jagtap@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Provides a helpful error when tests.py is invoked without the gem5 binary.
Before:
Running 0 tests
After:
gem5 binary 'quick/...' not an executable file
Change-Id: I1566802206c9e21ca89bd03e91db22844168a085
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
The notion of forward dependencies is just expressing the same
dependency but at the other end of the dependency edge, i.e. at
the dependee rather than the depender. As there is no more
'power' here, it's strictly a convenience feature for handling
dependencies with tags that are not in the upstream repository.
Change-Id: Ic7c68de6aff4094aaa12de62cdf690a5dc65ccb5
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
This commit supports the use case of transitioning tags and their
associated checkpoint rewrites out of use for whatever reason. Just
replace the upgrader() method with a downgrader() method that performs
the appropriate inverse operation.
The tag name is still used, but only in this negative, 'zombie' state,
as it will be removed from the tags in the checkpoint and gem5 binary.
Change-Id: If9d26cccfe8449e026762b1a72f0c2ae5a9cf2d7
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
The system calls tested in rv64i.cpp in RISC-V's insttest suite have
different behavior depending on the operating system and file system they
are run on. This patch ignores the output of those tests and only
ensures that the instructions in RV64I complete successfully.
[Change deletion of ECALL test to block comment.]
[Restore ECALL test but remove test output to test only for completion
without error.]
[Update patch description and again try to push EMPTY files for rv64i
tests.]
The current TLM bridge only provides a Slave Port that allows the gem5
world to send request to the SystemC world. This patch series refractors
and cleans up the existing code, and adds a Master Port that allows the
SystemC world to send requests to the gem5 world.
This patch:
* Update the README
The rr arbiter pointer in garnet was getting updated on every request,
even if there is no grant. This was leading to a huge variance in wait
time at a router at high injection rates.
This patch corrects it to update upon a grant.
Rather than having the 1st line on the Log line and every other line on its
own, add a new line to have a common format for all of them. Makes parsing
a lot easier.
Reviewed at http://reviews.gem5.org/r/3808/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
When in 64-bit mode, if the stack is accessed implicitly by an instruction
the alternate address prefix should be ignored if present.
This patch adds an extra flag to the ldstop which signifies when the
address override should be ignored. Then, for all of the affected
instructions, this patch adds two options to the ld and st opcode to use
the current stack addressing mode for all addresses and to ignore the
AddressSizeFlagBit. Finally, this patch updates the x86 TLB to not
truncate the address if it is in 64-bit mode and the IgnoreAddrSizeFlagBit
is set.
This fixes a problem when calling __libc_start_main with a binary that is
linked with a recent version of ld. This version of ld uses the address
override prefix (0x67) on the call instruction instead of a nop.
Note: This has not been tested in compatibility mode and only the call
instruction with the address override prefix has been tested.
See [1] page 9 (pdf page 45)
For instructions that are affected see [1] page 519 (pdf page 555).
[1] http://support.amd.com/TechDocs/24594.pdf
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
In some newer Linux distributions, env python default to Python 3.0. This
patch explicitly uses "python2" instead of just "python" for all scripts
that use #!
Reported-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
The current TLM bridge only provides a Slave Port that allows the gem5
world to send request to the SystemC world. This patch series refractors
and cleans up the existing code, and adds a Master Port that allows the
SystemC world to send requests to the gem5 world.
This patch:
* Add callbacks for the Gem5SimControl that are called at before and
* after simulate()
Reviewed at http://reviews.gem5.org/r/3799/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
The current TLM bridge only provides a Slave Port that allows the gem5
world to send request to the SystemC world. This patch series refractors
and cleans up the existing code, and adds a Master Port that allows the
SystemC world to send requests to the gem5 world.
This patch:
* Pay for the header delay that the gem5 XBar annotates to packets.
Reviewed at http://reviews.gem5.org/r/3798/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
The current TLM bridge only provides a Slave Port that allows the gem5
world to send request to the SystemC world. This patch series refractors
and cleans up the existing code, and adds a Master Port that allows the
SystemC world to send requests to the gem5 world.
This patch:
* bugfix: The BEGIN_RESP also needs to be handled when END_REQ was
* skipped
and '&trans == blockingRequest && phase == tlm::BEGIN_RESP'
evaluates to true.
Reviewed at http://reviews.gem5.org/r/3797/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
The current TLM bridge only provides a Slave Port that allows the gem5
world to send request to the SystemC world. This patch series refractors
and cleans up the existing code, and adds a Master Port that allows the
SystemC world to send requests to the gem5 world.
This patch:
* Implement 'pipe through' for gem5 Packets (see explanation below)
Basically, this patch ensures that all transactions that originated in the
gem5 world are converted back to the original packet when entering the gem5
world. So far, this only worked for packets that are responded to by a
SyctemC component (e.g. when a gem5 CPU sends a request to a SystemC
memory). By implementing the 'pipe through' this patch ensures, that
packets that are responded to by a gem5 component (e.g. when a gem5 CPU
sends a request to a gem5 memory via a SystemC interconnect) are handled
properly.
Reviewed at http://reviews.gem5.org/r/3796/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Changeset 11798:3a490c57058d
---------------------------
misc: Clean up and complete the gem5<->SystemC-TLM bridge [5/10]
The current TLM bridge only provides a Slave Port that allows the gem5
world to send request to the SystemC world. This patch series refractors
and cleans up the existing code, and adds a Master Port that allows the
SystemC world to send requests to the gem5 world.
This patch:
* Introduce transactor modules that represent the gem5 ports in the
* SystemC world.
* Update the SimControl module and let it keep track of the gem5 ports.
Reviewed at http://reviews.gem5.org/r/3775/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
The current TLM bridge only provides a Slave Port that allows the gem5
world to send request to the SystemC world. This patch series refractors
and cleans up the existing code, and adds a Master Port that allows the
SystemC world to send requests to the gem5 world.
This patch:
* Move common code of the example to a common directory. Move the cli
* parsing from the SimControl module to a separate example object. Add
* comments describing the Gem5SimControl module.
Testing Done: Examples compile and run.
Reviewed at http://reviews.gem5.org/r/3695/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
The current TLM bridge only provides a Slave Port that allows the gem5
world to send request to the SystemC world. This patch series refractors
and cleans up the existing code, and adds a Master Port that allows the
SystemC world to send requests to the gem5 world.
This patch:
* Simplify the Slave Port by using a simple_initiator_socket.
Testing Done: Example applications are still running.
Reviewed at http://reviews.gem5.org/r/3686/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
The current TLM bridge only provides a Slave Port that allows the gem5
world to send request to the SystemC world. This patch series refractors
and cleans up the existing code, and adds a Master Port that allows the
SystemC world to send requests to the gem5 world.
This patch:
* Add the Master Port. Add an example application that isslustrates its
* use.
Testing Done: A simple example application consisting of a TLM traffic
generator and a gem5 memory is part of the patch.
Reviewed at http://reviews.gem5.org/r/3528/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
The current TLM bridge only provides a Slave Port that allows the gem5
world to send request to the SystemC world. This patch series refractors
and cleans up the existing code, and adds a Master Port that allows the
SystemC world to send requests to the gem5 world.
This patch:
* Restructure the existing sources in preparation of the addition of the
* new
Master Port.
* Refractor names to allow for distinction of the slave and master port.
* Replace the Makefile by a SConstruct.
Testing Done: The examples provided in util/tlm (now
util/tlm/examples/slave_port) still compile and run error free.
Reviewed at http://reviews.gem5.org/r/3527/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
The Request constructor requires a MasterID. However, an external
transactor has no chance of getting a MasterID as it does not have a
pointer to the System. This patch adds a MasterID to ExternalMaster to
allow external modules to easily genrerate new Requests.
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
The CxxConfigManager schould create objects by traversing the object tree
starting from the root object. However, currently objects are created in
aplphabetical order, which only works if the root object alphabetically
comes before any system object (e.g. 'root' < 'system'. Otherwise (e.g.
'a_system' < 'root'), object construction may fail. The reason for this
behaviour is, that the call to findObject() in the sorting code also
constructs the object if it is not yet existent. Then findTraversalOrder()
calls findObject("root") and subseqeuently calls findObject() on all the
children, and so on. However, the call to findTraversalOrder() is
redundant, since all objects are already created in alphabetical order.
This patch simply removes the alphabetical ordering, leading to the objects
being created starting from 'root'.
Reviewed at http://reviews.gem5.org/r/3778/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Implementing the Module as an sc_channel allows derived classes to provide
SystemC interfaces. Other SystemC modules can connect to these interfaces.
This meachanism can be used to control gem5 and acces gem5 components from
within arbitrary SystemC moduels. Since sc_channel is derived from
sc_module, this patch does not break compatibility with existing code.
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Seeing build breakage after brandon@11801:
[ CXX] X86/sim/process.cc -> .o build/X86/sim/process.cc:137:64:
error: field '_pid' is uninitialized when used here
[-Werror,-Wuninitialized] static_cast<PageTableBase *>(new
ArchPageTable(name(), _pid, system)) : ^ build/X86/sim/process.cc:138:64:
error: field '_pid' is uninitialized when used here
[-Werror,-Wuninitialized] static_cast<PageTableBase *>(new
FuncPageTable(name(), _pid))), ^ 2 errors generated.
Testing Done: Compiles now on FreeBSD 10 with clang.
Reviewed at http://reviews.gem5.org/r/3804/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
See developers mailing list. Trying to unbreak statfs.
Testing Done:
Builds on FreeBSD now.
Reviewed at http://reviews.gem5.org/r/3803/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Various changes we found needed to build gem5 successfully on
FreeBSD.
Reviewed at http://reviews.gem5.org/r/3378/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
There are drivers writing to WUFC uncondtionally of anything. In order to
not panic gem5 in these cases, ignore writes to WUFC and WUS as we do for
WUC. Similarly return 0 (default reset value) on reads.
Testing Done: Booted in FS with such a driver revision which would
previously panic and now boots fine.
Reviewed at http://reviews.gem5.org/r/3791/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Trying to read MISCREG_CTR_EL0 on AArch64 returned 0 as is was not
implmemented. With that an operating system relying on the cache line
sizes reported in order to manage the caches would (a) panic given the
returned value 0 is not valid (high bit is RES1) or (b) worst case would
assume a cache line size of 4 doing a tremendous amount of extra
instruction work (including fetching). Return the same values as for ARMv7
as the fields seem to be the same, or RES0/1 seem to be reported
accordingly for AArch64
In collaboration with: Andrew Turner
Testing Done: Checked on FreeBSD boots with extra printfs; also observed a
reduction of a factor of about 10 in instruction fetches for a simple
micro-test.
Reviewed at http://reviews.gem5.org/r/3667/
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Python's header files set various compiler macros (e.g.,
_XOPEN_SOURCE) unconditionally. This triggers preprocessor warnings
that end up being treated as errors. The Python integration manual [1]
strongly recommends that Python.h is included before any system
header. The style guide used to mandate that Python.h is included
first in any file that needs it. This requirement was changed to
always include a source file's main header first, which ended up
triggering these errors.
This change updates the style checker to always include Python.h
before the main header file.
[1] https://docs.python.org/2/extending/extending.html
Change-Id: Id6a4f7fc64a336a8fd26691a0ca682abeb1d1579
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Pierre-Yves Péneau <pierre-yves.peneau@lirmm.fr>
