| Age | Commit message (Collapse) | Author |
|---|
|
This commit adds a new generic vector register to have a cleaner
implementation of SIMD ISAs.
Nathanael's idea, Rekai's implementation.
Change-Id: I60b250bba6423153b7e04d2e6988d517a70a3e6b
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2704
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
The Result union used to collect the result of an instruction is now a
class of its own, with its constructor, and explicit casting methods for
cleanliness.
This is also a stepping stone to have vector registers, and instructions
that produce a vector register as output.
Change-Id: I6f40c11cb5e835d8b11f7804a4e967aff18025b9
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2703
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
With the hierarchical RegId there are a lot of functions that are
redundant now.
The idea behind the simplification is that instead of having the regId,
telling which kind of register read/write/rename/lookup/etc. and then
the function panic_if'ing if the regId is not of the appropriate type,
we provide an interface that decides what kind of register to read
depending on the register type of the given regId.
Change-Id: I7d52e9e21fc01205ae365d86921a4ceb67a57178
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
[ Fix RISCV build issues ]
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2702
|
|
Mimic the changes done on the architectural register indexes on the
physical register indexes. This is specific to the O3 model. The
structure, called PhysRegId, contains a register class, a register
index and a flat register index. The flat register index is kept
because it is useful in some cases where the type of register is not
important (dependency graph and scoreboard for example). Instead
of directly using the structure, most of the code is working with
a const PhysRegId* (typedef to PhysRegIdPtr). The actual PhysRegId
objects are stored in the regFile.
Change-Id: Ic879a3cc608aa2f34e2168280faac1846de77667
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2701
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Replace the unified register mapping with a structure associating
a class and an index. It is now much easier to know which class of
register the index is referring to. Also, when adding a new class
there is no need to modify existing ones.
Change-Id: I55b3ac80763702aa2cd3ed2cbff0a75ef7620373
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
[ Fix RISCV build issues ]
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2700
|
|
The ARM MiscRegs implementation has two interfaces: 'normal'
and 'no effect'. The latter acts as a way to access the
backing store without architectural 'effects'. For instance,
a normal write to a timer compare value would call into the
timer model to emulate the device. The 'no effect' interface,
however, would just write the value into the register backing
store and do nothing else.
For Kvm execution, a delicate balance must be struck for the
timer device specifically. We need the code in the model
to be run, because it contains state other than the register
backing store that must stay in sync. On the other hand, we
don't necessarily want the timer model to schedule gem5
events when this happens.
In this commit, we ensure that we use the 'effectful'
MiscReg interface when copying the CP15 timer registers
from Kvm back into gem5. The prior commit makes sure
that this doesn't generate unnecessary timer events
or interrupts.
Change-Id: Id414c2965bd07fc21ac95e3d581ccc9f55cef9f9
Reviewed-on: https://gem5-review.googlesource.com/3543
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
The timer device exposed via the ARM ISA, also known as the
"CP15 timer" due to its legacy coprocessor encodings, is
implemented by the GenericTimerISA class. During Kvm
execution, however, this functionality is directly emulated
by the hardware.
This commit subclasses the GenericTimer, which is (solely)
used by GenericTimerISA, to facilitate Kvm in much the same
way as the prior GIC changes: the gem5 model is used as the
backing store for state, so checkpointing and CPU switching
work correctly, but isn't used during Kvm execution.
The added indirection prevents the timer device from creating
events when we're just updating its state, but not actually
using it for simulation.
Change-Id: I427540d11ccf049c334afe318f575146aa888672
Reviewed-on: https://gem5-review.googlesource.com/3542
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Having timer events stored in checkpoints complicates Kvm
execution. We change the timer behavior so that it always
deschedules any pending events on a drain() and recreates
them on a drainResume(), thus they will never appear in
checkpoints henceforth. This pattern of behavior makes
it simpler to handle Kvm execution, where the hardware
performs the timer function directly.
Change-Id: Ia218868c69350d96e923c640634d492b5c19cd3f
Reviewed-on: https://gem5-review.googlesource.com/3541
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
The check was nearly completely generic anyway,
with the exception of the Kvm CPU type.
This will make it easier for other parts of the
codebase to do similar checks.
Change-Id: Ibfdd3d65e9e6cc3041b53b73adfabee1999283da
Reviewed-on: https://gem5-review.googlesource.com/3540
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: I3395e64311f6aa7bbfb6eee9bfec82e832bcbd4d
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3901
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: I864b5d9ed655cc52e440e2eb54987e8ff9a73296
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3900
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: I6a3a57e3067c247bd6ce6f01ac9459883f4aae2c
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3880
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
32bit and 64bit Linux have different arguments passed to the
__switch_to() function that gem5 hooks into in order to collect context
switch statistics. 64bit Linux provides the task_struct pointer to the
next task that will be switched to, which means we don't have to look
up the task_struct from thread_info as we do in 32bit ARM Linux.
This patch adds a second set of accessors to ThreadInfo to extract
details such as the pid, tgid, task name, etc., directly from a
task_struct. The existing accessors maintain their existing behavior by
first looking up the task_struct and then calling these new accessors.
A 64-bit variant of the DumpStatsPCEvent class is added that uses these
new accessors to get the task details for the context switch dumps
directly from the task_struct passed to __switch_to().
Change-Id: I63c4b3e1ad64446751a91f6340901d5180d7382d
Reviewed-on: https://gem5-review.googlesource.com/2640
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Pau Cabre <pau.cabre@metempsy.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
To prevent this warning from printing for *every* simulation, this patch
adds a check to only print the warning if we are not at the beginning of
simulation.
Change-Id: I7f6154f0ca26bef6280f909f799aa1c7936b624a
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/3840
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: Ie1df07b70776208fc3631a73d403024636fc05a9
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3749
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
|
|
Change-Id: I6b03cc6f67e76dffb79940431711ae6171901c6a
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3748
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: I08de5f72513645d1fe92bde99fa205dde897e951
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3747
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: Idd5992463bcf9154f823b82461070d1f1842cea3
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3746
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
NOTE: With this change there is a possibility for `DRAMCtrl::Rank`s
event names to not properly match the rank they were generated by. This
could occur if the public rank member is modified after the Rank's
construction. A patch would mean refactoring Rank and `DRAMCtrl`b to
privatize many of the members of Rank behind getters.
Change-Id: I7b8bd15086f4ffdfd3f40be4aeddac5e786fd78e
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3745
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
In order to replicate the same `name()` output with `PacketQueue`, subclasses
using EventFunctionWrapper must initialize PacketQueue with their own name so
the sendEvent holds the name of the subclass.
Change-Id: Ib091e118bab8858192e1d1370d61def42958ec29
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3744
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
Add EventFunctionWrapper, an event wrapper which takes any callable
object to use as its callback. (This includes c++ lambdas, function
pointers, bound functions, and std::functions.)
Change-Id: Iab140df47bd0f7e4b3fe3b568f9dd122a43cee1c
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3743
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
|
|
This change was made so Rank objects have their name assigned
when they are instantiated. Therefore, they can initialize their
member objects with their name and it is less likely to change during
runtime.
(NOTE: I would recommend hiding the fields which would cause the name to
change behind getters. Since modification of `Rank.rank` during runtime
will cause the `name()` to change.)
Change-Id: Id51c3553b40e489792c57950e18b8ce927e43173
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3742
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
`DelayFunction` is unused.
Change-Id: I28aa756054c9b121fe4cfa65c393366f26ccb128
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3741
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: I953521572e6ace475b656369c9f07ddfa50d731a
Signed-off-by: Gedare Bloom <gedare@rtems.org>
Reviewed-on: https://gem5-review.googlesource.com/3263
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: I6d8a5e3795291b2a4cce022f555cf4b04f997538
Signed-off-by: Gedare Bloom <gedare@rtems.org>
Reviewed-on: https://gem5-review.googlesource.com/3262
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
This commit adds support for diod to use a unix socket, rather
than a TCP port. We don't rely on the IP-based connection as we
directly use pipes to interact with diod. This allows it to work
on any system, even if the specific port is taken by another diod
instance (or similar). Secondly, the Unix socket could in theory
be used to debug. However, this functionality has not been
tested.
Change-Id: I616e0ad8768da1dfc867de3af98cdfbb22a72d63
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2820
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
Change-Id: I912601b6f781a0bbedd06583c059589374f6d5c6
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3720
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Joe Gross <joe.gross@amd.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
GDB breaks if more bytes are sent than the transmitted registers
actually need. Therefore the GdbRegCache struct needs to be packed to
prevent padding at the end.
Change-Id: Ib2c14eb70becdac609eb4f475d5dddbd5bcc60da
Signed-off-by: Matthias Hille <matthiashille8@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/3020
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
This patch fix some statistics that in presence of a resetStats
instruction were not reseted. This bug makes impossible to obtain
reliable network statistics when the simulation doesn't start from tick
zero.
Change-Id: Ibec45f08d95bf0a533d94b70ec960719206ae945
Maintainer: Tushar Krishna <tushar@ece.gatech.edu>
Reviewed-on: https://gem5-review.googlesource.com/3700
Reviewed-by: Jieming Yin <bjm419@gmail.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Change-Id: Iac3d15719b2bbc426020a27d6b47a4baaab078c7
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2907
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Previously the directory covered a flat address range that always
started from address 0. This change adds a vector of address ranges
with interleaving and hashing that each directory keeps track of and
the necessary flexibility to support systems with non continuous
memory ranges.
Change-Id: I6ea1c629bdf4c5137b7d9c89dbaf6c826adfd977
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2903
Reviewed-by: Bradford Beckmann <brad.beckmann@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
When it comes time to send a packet with the i8254xGBe model hooked up to
EtherTap and while running in KVM mode, the packet will first go to the
EtherTap over the network style port between them. EtherTap, because it's
not actually a model of anything in the simulation, will immediately pass
the packet off to the real network and report that the transmission was
successful to the i8254xGBe. The i8254xGBe will notice that it still has
stuff it can send (the KVM mode CPU has no trouble keeping it full) and
will, without returning and collapsing the stack, immediately call back
into EtherTap with the next packet. This loop repeats, continually
deepening the stack, until gem5 crashes with a segfault.
To break this loop, a few small changes have been made. First, txFifoTick
has been repurposed slightly so that it continuously keeps track of
whether there's still work to do to flush out the fifo during the current
tick. The code in txWire has been adjusted slightly so that it clears that
variable at the start (also removing some redundancy), so that other code
can set it again if more work needs to be done. Specifically, the
ethTxDone function will set that flag.
If there's more work to be done flushing the Fifo while in tick(), it
will loop until txFifoTick stays cleared, meaning either the Fifo is
empty, or the object on the other end hasn't said it's done yet.
Finally, a new bool member called inTick has been added which keeps track
of whether the tick() function is still active somewhere in the callstack.
If it is, then the tick event shouldn't be rescheduled in ethTxDone, since
tick will take care of that before it returns. It won't check to see if it
needs to, and so without this check there's a panic from scheduling the
same event twice.
It's not completely clear that the Fifo should send packets over and over
as fast as the other side accepts them within the same tick, although it's
not clear that it shouldn't either. If not, then probably all that would
need to change would be to remove the "while" loop so that the tick event
would be rescheduled, and the Fifo would be further emptied the next time
around.
Change-Id: I653379b43389d0539ecfadb3fc6c40e38a8864c2
Reviewed-on: https://gem5-review.googlesource.com/3642
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
gcc has had a lot of problems with incremental linking and partial linking
at the same time. Basically, the partial link assumes that it's the only
link that's going to happen, and it converts weak external symbols into
regular external symbols. Then when the real final link happens, those
symbols are duplicated and the link fails.
Versions of gcc 6 and greater add an option called -flinker-output which
lets you tell the linker to do an incremental link. Unfortunately, other
bugs make that fail, and so gcc 6 doesn't work either. Hopefully version
7 works better.
A --force-lto option was added so that, when only one of lto and partial
linking is available, you can switch from having partial linking to having
lto.
Change-Id: I5e293f5cfb07a14343dc74030d99cb161fb8bbbe
Reviewed-on: https://gem5-review.googlesource.com/3680
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Some of the macros, notably panic, uses exit(). Callers shouldn't have to
know that or have coincidentally included cstdlib, the provider of exit,
themselves.
Change-Id: I634602ed1795dcc8897b4bddb1167c96763acc18
Reviewed-on: https://gem5-review.googlesource.com/3601
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Fix load_addr_mask in VExpress_GEM5_V1 in order to boot with the 64-bit
kernel.
Change-Id: I13a0a752c60e53262a245cb24b16606071041397
Reviewed-on: https://gem5-review.googlesource.com/3643
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
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>
|
|
Change-Id: I31808b6d7ca2bc2af41deaec747e3a13bd4f77d2
Signed-off-by: Gedare Bloom <gedare@rtems.org>
Reviewed-on: https://gem5-review.googlesource.com/3261
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.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 PMU model currently doesn't calculate the PMU event counter index
correctly for writes to the PMEVTYPER[0-5]_EL0 registers. Fix this
obvious mistake.
Change-Id: I2913eedddeb98480660e2d63948f6d727adf5ab8
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sudhanshu Jha <sudhanshu.jha@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3121
Reviewed-by: Curtis Dunham <curtis.dunham@arm.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>
|
