The object is called EtherTap (as opposed to EtherTapStub, what the former
EtherTap was renamed to), and its existance is gated on the linux/if_tun.h
header file existing. That's probably overly strict, but it will hopefully
be minimally likely to break the build for other systems.
Change-Id: Ie03507fadf0d843a4d4d52f283c44a416c6f2a74
Reviewed-on: https://gem5-review.googlesource.com/3646
Reviewed-by: Nathan Binkert <nate@binkert.org>
Maintainer: Nathan Binkert <nate@binkert.org>
A lot of the implementation of EtherTapStub can be shared with a version
which uses a tap device directly. This change factors out those parts to
accommodate that.
Change-Id: I9c2e31f1be139ca73859a83f05457cef90101006
Reviewed-on: https://gem5-review.googlesource.com/3645
Reviewed-by: Nathan Binkert <nate@binkert.org>
Maintainer: Nathan Binkert <nate@binkert.org>
The EtherTap object is going to be reworked so that it connects to a tap
device directly, but it's worthwhile to still be able to use the m5tap
utility (util/tap) to send/receive packets on systems which don't support
tap but do support the pcap API. It can also be used to replay ethernet
frames, to capture the ethernet frames coming from gem5 for analysis, to
programmatically consume and/or generate the frames, or even to forward
them to/from a remote system.
Change-Id: Ic7bd763d86cd913ac373dd10a8d6d1fc6b35f95a
Reviewed-on: https://gem5-review.googlesource.com/3644
Reviewed-by: Nathan Binkert <nate@binkert.org>
Maintainer: Nathan Binkert <nate@binkert.org>
There needs to be a SlavePort called "tap" for the ethertap device to be
able to connect to the gem5 network successfully.
Change-Id: I1ad81219f612fd1ec278c6148af728d20bc916da
Reviewed-on: https://gem5-review.googlesource.com/3580
Reviewed-by: Nathan Binkert <nate@binkert.org>
Maintainer: Nathan Binkert <nate@binkert.org>
Previously the Sequencer upon a Store Conditional would
unconditionally set the data of the memory location. This change
checks and prevents a failed Store Conditional from modifying any
data.
Change-Id: Id63c9579d8f054f0e95c6d338a7e31aa48762755
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2902
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Bradford Beckmann <brad.beckmann@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Previously proxy vector parameters would resolve correctly only for
Parent.all. Any other proxy such as Parent.any, or exact ones such as
Parent.addr_range would resolve to a *vector* of the right value
resulting into a vector of a vector. For example if we set:
DirectoryController0.addr_range = [0x100000-0x1fffff, 0x200000-0x2fffff]
DirectoryMemory0.addr_range = Parent.addr_range
where DirectoryController0 is the parent SimObject of DirectoryMemory0
after unproxying the Parent.addr_range VectorParam we would get
DirectoryMemory0.addr_range = [[0x100000-0x1fffff, 0x200000-0x2fffff]]
This change unifies handling of all three proxies to the same correct
unproxy mechanism.
Change-Id: Ie5107f69f58eb700b3e1b92c55210e0d53e6788d
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2901
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Remove redundant information from the ExtMachInst, hash the vex
information to ensure the decode cache works properly, print the vex info
when printing an ExtMachInst, consider the vex info when comparing two
ExtMachInsts, fold the info from the vex prefixes into existing settings,
remove redundant decode code, handle vex prefixes one byte at a time and
don't bother building up the entire prefix, and let instructions that care
about vex use it in their implementation, instead of developing an entire
parallel decode tree.
This also eliminates the error prone vex immediate decode table which was
incomplete and would result in an out of bounds access for incorrectly
encoded instructions or when the CPU was mispeculating, as it was (as far
as I can tell) redundant with the tables that already existed for two and
three byte opcodes. There were differences, but I think those may have
been mistakes based on the documentation I found.
Also, in 32 bit mode, the VEX prefixes might actually be LDS or LES
instructions which are still legal in that mode. A valid VEX prefix would
look like an LDS/LES with an otherwise invalid modrm encoding, so use that
as a signal to abort processing the VEX and turn the instruction into an
LES/LDS as appropriate.
Change-Id: Icb367eaaa35590692df1c98862f315da4c139f5c
Reviewed-on: https://gem5-review.googlesource.com/3501
Reviewed-by: Joe Gross <joe.gross@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
When the LiveProcess class was renamed to be just Process, the CL author
also changed the syscall function from a virtual function into a regular
one. Unfortunately, the I386Process class overrode the syscall function
to adjust the return address so that control would return to the right
place. Without that adjustment, 32 bit x86 process would segfault and die
immediately after their first system call.
This change reinstates the virtual specifier on the base syscall function,
and adds an override keyword on the I386Process's version so that it won't
be orphaned again in the future. It also fixes some small style issues the
style checker script complained about.
Change-Id: I0d1178ea0eda6676050c8fc043820a2bb4d99c0d
Reviewed-on: https://gem5-review.googlesource.com/3500
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The current implementation of reference counting for PyEvents only
partially works. The native object is currently kept alive while it is
in the event queue. However, if the Python object goes out of scope,
the Python side of this object is garbage collected which leaves a
"dangling" native object. This results in confusing error messages
where PyBind is unable to find the Python implementation of an event
when it is triggered.
Implement reference counting using the generalized reference counting
API instead.
Change-Id: I4e8e04abc4f61dff238d718065f5371e73b38ab3
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3222
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
We currently only support deleting an event if it is triggered and not
re-scheduled. This is fine for most native code. However, there are
cases where Python needs to count references to make sure that the
Python object stays live while the native object is live.
Generalise the mechanism used to implement by adding reference
counting hooks to the event base class:
* Event::acquire() / Event::acquireImpl()
* Event::release() / Event::releaseImpl()
These calls can be used to implement both reference counting and the
existing AutoDelete functionality. The default implementation in Event
maintains backwards compatibility with the existing AutoDelete feature
by ignoring acquireImpl() and deleting the event on releaseImpl() if
it isn't scheduled anymore.
Since AutoDelete functionality is no longer the only way events can be
managed, this change introduces the new Managed flag. This flag
activates automatic memory management. The acquireImpl()/releaseImpl()
methods are only called from acquire()/release() it is set. To
maintain backwards compatibility, AutoDelete is used as an alias for
Managed.
Change-Id: I5637984c906a9d44c22780712cf1c521b8297149
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3221
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
This patch fixes a problem with RISC-V initial stack setup in SE mode
where the AT_RANDOM aux vector value contains an address that is too
close to the top of the stack and doesn't fit the required 16 bytes. To
fix this, the program header table was added to the top of the stack
just like the RISC-V proxy kernel does.
Change-Id: I814562e060ff041cd0d7a7c54c3685645bd325a3
Reviewed-on: https://gem5-review.googlesource.com/3401
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Alec Roelke <ar4jc@virginia.edu>
The ISA code for ARM calculates min and max elements for types using
bit manipulation. That triggers some warnings, treated as errors, as
the compiler can tell that there is an overflow and the sign
flips. Fixed using standard lib definitions instead.
Change-Id: Ie2331b410c7f76d4bd87da5afe9edf20c8ac91b3
Reviewed-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3481
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The PyBind wrappers could potentially delete SimObjects if they don't
have any references. This is not desirable since there could be
pointers to such objects within the C++ world. This problem doesn't
normally occur since Python typically holds a pointer to the root node
as long as the simulator is running.
Prevent SimObject and Param deletion by using a PyBind-prescribed
unique_ptr with a dummy deleter as the pointer wrapper for the Python
world.
Change-Id: Ied14602c9ee69a083a69c5dae1b5fcf8efb4548a
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3224
Reviewed-by: Gabe Black <gabeblack@google.com>
There is a weird issue with the PyBind wrapper of
vector<AddrRange>. Assigning new values to a param that is a vector of
AddrRange sometimes results in an out-of-bounds memory access.
We work around this issue by treating AddrRange vectors as opaque
types. This slightly changes the semantics of the wrapper since Python
now manipulates the real object rather than a copy that has been
converted to a list.
Change-Id: Ie027c06e7a7262214b43b19a76b24fe4b20426c5
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Timothy Hayes <timothy.hayes@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3223
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Compiling gem5 with recent version of clang (4 and 5) triggers
warnings that are treated as errors:
* Global templatized static functions result in a warning if they
are not used. These should either be declared as static inline or
without the static identifier to avoid the warning.
* Some templatized classes contain static variables. The
instantiated versions of these variables / templates need to be
explicitly declared to avoid a compiler warning.
Change-Id: Ie8261144836e94ebab7ea04ccccb90927672c257
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3420
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
The new version modularizes the implementation of the various commands,
gets rid of dynamic allocation of the register cache, fixes some small
style problems, and uses exceptions to simplify error handling internal to
the GDB stub.
Change-Id: Iff3548373ce4adfb99106a810f5713b769df89b2
Reviewed-on: https://gem5-review.googlesource.com/3280
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
If the operands were 64 bit, an intermediate calculation could lose a
carry bit. This change rearranges that intermediate calculation if the
operand width is large, and reworks the microop implementation in general
in an attempt to make it easier to understand.
Change-Id: Ib36333f3f2695a33cd9623e43682de22ebd2e7ea
Reviewed-on: https://gem5-review.googlesource.com/3381
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Add a helper function, m5.event.create(), to create events from
Python. This function takes a callable Python object (e.g., a
function) as an argument and optionally a priority as a keyword
argument. This function was accidentally dropped from the public API
when switching to PyBind.
Change-Id: Icbd0e392d9506934ec2c9f541199aa35c1c2df8c
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3220
Reviewed-by: Gabe Black <gabeblack@google.com>
The style checker complains about line length and ordering for these
files. This fix should make these two files kosher.
Change-Id: I822a0518a98d9e379a543d2017e90c4e9666a58d
Reviewed-on: https://gem5-review.googlesource.com/3380
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
If a (regular) store is followed closely enough by a locked load that
overlaps, the LSQ will forward the store's data to the locked load and
never tell the cache about the locked load. As a result, the cache will
not lock the address and all future store-conditional requests on that
address will fail. This patch fixes that by preventing forwarding if
the memory request is a locked load and adding another case to the LSQ
forwarding logic that delays the locked load request if a store in the
LSQ contains all or part of the data that is requested.
[Merge second and last if blocks because their bodies are the same.]
Change-Id: I895cc2b9570035267bdf6ae3fdc8a09049969841
Reviewed-on: https://gem5-review.googlesource.com/2400
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
We don't implement the GICD_IGROUPRn registers, which is allowed, but
to be correct, they should be RAZ/WI (read as zero, writes ignored).
Change-Id: I8039baf72f45c0095f41e165b8e327c79b1ac082
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2620
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Currently, if the remote gdb stub fails to read a byte from an incoming
packet because the connection has been dropped, the read call will return
anyway and the calling code will have no way to know something bad
happened. It might reattempt the read over and over again waiting for some
particular byte, doomed to never make forward progress.
This change modifies the remote GDB code so that if a read or write call
fails, it will instead detach from the debugger and continue. Before this
change, When simulating a port scan, ie connecting to the debugger port
and then immediately dropping the connection using this command:
nc -v -n -z -w 1 127.0.0.1 7000
gem5 would enter the previously described death spiral. After it, gem5
detaches from the bad connection and resumes execution. Subsequently
attaching with gdb was successful.
This code is written in a C centric style, and would benefit from some
refactoring.
Change-Id: Ie3c0bb35b9cfe3671d0f731e3907548bae0d292f
Reviewed-on: https://gem5-review.googlesource.com/3180
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Clang's UBSAN implementation complains about macros that expand to
expressions that contain 'defined'. Explicitly set the various feature
macros to 1 or 0 to avoid this issue.
Change-Id: Iba239dacfe526c43ab9c5da5183a350fc4fdc57d
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3241
Factor out the ISA ness of the switching header generating function. Also
turn it into a SCons builder which builds a single header, and a wrapping
method which uses the builder on a group of header files which all target
the same subdirectory.
Change-Id: I87705f97b6ebd9baebd4ebcfea19cc1218a64ad0
Reviewed-on: https://gem5-review.googlesource.com/2983
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
This option invokes the Listener::loopbackOnly() static function which
will make the port listeners bind to the loopback device exclusively and
ignore connections on other devices. That prevents external agents like
port scanners from disrupting simulations with spurious connections.
Change-Id: I46b22165046792a6f970826c109bdbce7db25c84
Reviewed-on: https://gem5-review.googlesource.com/3082
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The loopback device will allow access to various services like remote GDB
debugging, connecting to the terminal, etc., without letting external
agents like port scanners connect and disrupting the simulation.
Change-Id: I76dccbf152fa278ae9f342b25f7e345a1329fbe4
Reviewed-on: https://gem5-review.googlesource.com/3080
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The PyBind11 changes slightly modified gem5's internal debug
interfaces. The corresponding change to the public API went missing
before the new bindings were merged. This change updates the Python
glue to use the new interface.
Change-Id: I3ecca5a3f6c35b99d55126d697371124f81a12dd
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Matteo Andreozzi <matteo.andreozzi@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3140
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Add support for a memory mapped m5op interface. When enabled, the TLB
intercepts accesses in the 64KiB region designated by the
ArmTLB.m5ops_base parameter. An access to this range maps to a
specific m5op call. The upper 8 bits of the offset into the range
denote the m5op function to call and the lower 8 bits denote the
subfunction.
Change-Id: I55fd8ac1afef4c3cc423b973870c9fe600a843a2
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2964
The state transfer code wasn't reading back PSTATE correctly from the
CPU prior to updating the thread context and was incorreclty writing
the register as a 32-bit value when updating KVM. Correctly read back
the state before updating gem5's view of PSTATE and cast the value to
a uint64_t.
Change-Id: I0a6ff5b77b897c756b20a20f65c420f42386360f
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2963
Reviewed-by: Rahul Thakur <rjthakur@google.com>
For Value() nodes, the get_contents() method and the get_text_contents()
method are just aliases to the same thing, both of which return a value
which has already been converted using str(). The str() which was included
explicitly in the SConscript was redundant, except that it showed that the
value from get_contents was being treated as a string. To avoid the
redundancy but to still leave a hint to the value's type, this change
converts those bits of code to use get_text_contents() and removes the
str().
Change-Id: I8f7da9b652f749e741b553c9a0e2248ae15ec3ca
Reviewed-on: https://gem5-review.googlesource.com/3084
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Use the PyBind11 wrapping infrastructure instead of SWIG to generate
wrappers for functionality that needs to be exported to Python. This
has several benefits:
* PyBind11 can be redistributed with gem5, which means that we have
full control of the version used. This avoid a large number of
hard-to-debug SWIG issues we have seen in the past.
* PyBind11 doesn't rely on a custom C++ parser, instead it relies on
wrappers being explicitly declared in C++. The leads to slightly
more boiler-plate code in manually created wrappers, but doesn't
doesn't increase the overall code size. A big benefit is that this
avoids strange compilation errors when SWIG doesn't understand
modern language features.
* Unlike SWIG, there is no risk that the wrapper code incorporates
incorrect type casts (this has happened on numerous occasions in
the past) since these will result in compile-time errors.
As a part of this change, the mechanism to define exported methods has
been redesigned slightly. New methods can be exported either by
declaring them in the SimObject declaration and decorating them with
the cxxMethod decorator or by adding an instance of
PyBindMethod/PyBindProperty to the cxx_exports class variable. The
decorator has the added benefit of making it possible to add a
docstring and naming the method's parameters.
The new wrappers have the following known issues:
* Global events can't be memory managed correctly. This was the
case in SWIG as well.
Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-by: Andrew Bardsley <andrew.bardsley@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2231
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Pierre-Yves Péneau <pierre-yves.peneau@lirmm.fr>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
A previous change forced scons to spawn child processes by exec-ing it
directly rather than going through the shell because the command line
length would be too long for the shell to handle. Now that incremental
linking should keep the command line lengths more under control, that
change should no longer be necessary.
Change-Id: I9e82a62083afd1414324a7fd697bd6d4b76367ae
Reviewed-on: https://gem5-review.googlesource.com/2947
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The groups won't be perfectly balanced or optimally planned, but this
requires no thought and breaks the object files down into a reasonable
number of reasonably sized groups.
Change-Id: I6542fc807aaf356a9be751093f68e2e29f0b1586
Reviewed-on: https://gem5-review.googlesource.com/2946
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The groups will be linked together into intermediate partially linked
object files. Right now the hierarchy is assumed to be flat, but with some
effort it could be extended to allow truly hierarchical linking.
Change-Id: I77b77710554e5f05e8b00720a0170afaf4afac2d
Reviewed-on: https://gem5-review.googlesource.com/2945
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
