It may be necessary to initialize the GuestABI Position type based on
the current state of the thread, for instance by reading the current
stack pointer.
This change makes it possible (but not mandantory) for an ABI to supply
a constructor for Position which accepts a ThreadContext * which it can
use to intiialize itself.
Change-Id: I5609b185f746368c5f9eb2a04074dcafa088f925
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23749
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Because the fast models (or at least the one we've looked at) give
access to the integer registers mostly based on the current view of
those registers, it does its own flattening and prevents accessing most
of the raw storage locations without this extra level of mapping. To
store to the flattened locations, we need to unflatten the indexes and
in one case shift the mode so that we get the right values.
Some registers which have irrelevant values for fast model (the "PC"
which is actually diverted elsewhere, the zero register, microcode
registers, and the "dummy" register), and those are left out of the
mapping so that they return 0 and blow up gem5 when someone attempts to
set them.
Change-Id: Ia2d315d5ca4c8a65b17ad52beff3a366ca8b3d46
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23791
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These don't have anything in them at the moment since making some ISA
methods virtual and not inlined will likely add overhead, specifically
the ones for flattening registers. Some code may need to be rearranged
to minimize that overhead before the ISA objects can be truly put
behind a generic interface.
Change-Id: Ie36a771e977535a7996fdff701ce202bb95c8c58
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25007
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Some AArch64 system registers report UNDEFINED behaviours if accessed
from EL2 or EL3 in a non-EL2 Host enabled (HCR_EL2.E2H == 0) environment.
Examples of these are seen in the Generic Timer system registers,
namely CNTP_CTL_EL02 or CNTKCTL_EL12.
This patch provides an ISA filter for specifying the above condition.
Change-Id: I240f9afdb000faf5d3c9274ba12bd4cc41fe8604
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24664
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These two functions were called in exactly one place one right after
the other, and served similar purposes.
This change merges them together, and cleans them up slightly. It also
removes checks for FullSystem, since those functions are only called
in full system to begin with.
Change-Id: I214f7d2d3f88960dccb5895c1241f61cd78716a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24904
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The call to initCPU was moved into initState in the base CPU class
since it should only really be called when starting a simulation
fresh. Otherwise checkpointed state will be loaded over the state of
the CPU anyway, so there's no reason to set up anything else.
Unfortunately that made it possible for the System level initialization
and the CPU initialization to happen out of order, effectively letting
initCPU clobber the state the System might have set up to prepare for
executing a kernel for instance.
To work around that issue, the call was moved to init which would
necessarily happen before initState, restoring the original ordering.
This change moves the change *back* into initState, but of the System
class instead of the CPU class. This makes it possible to guarantee
that OS initialization happens after initCPU since that's also done
by System subclasses, and they control when they call initCPU of the
base class.
This also slightly simmplifies when initCPU is called since we
shouldn't need to check whether a context is switched out or not. If
it's registered with the System object, then it should be in a
currently swapped in CPU.
This also puts the initCPU and startupCPU calls right next to each
other. A future change will take advantage of that and merge the
calls together.
Also, because there are already ISA specific subclasses of System
which already have specialized versions of initState, we should be
able to move the code in initCPU and startupCPU directly into those
subclasses. That will give those subclasses more flexibilty if, for
instance, they want all CPUs to start running in the BIOS like they
would on a real system, or if they want only the BSP to be active
as if the BIOS had already paused the APs before passing control to
a bootloader or OS.
This will also remove another two TheISA:: style functions, reducing
the number of global dependencies on a single ISA.
Change-Id: Ic56924660a5b575a07844a198f69a0e7fa212b52
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24903
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The requirement to have an environment variable exported to run a program
is not common, and many new users trip up on it.
Before this commit, M5_PATH was a requirement to run those scripts, or
else simulation would fail with:
IOError: Can't find a path to system files.
After this patch, as long as users indicate all required files with
command line options, M5_PATH is not needed.
This patch changes the M5_PATH semantics slightly to more closely match
PATH and so be more intuitive to users: after this commit, if the
given path contains a slash /, then the path is not searched for inside
M5_PATH, which is exactly how PATH works. Users can then select images
in the CWD with a leading ./ just as done for executables.
This is backwards incompatible if users were already specifying their paths
as ./, but this interface feels saner, because otherwise writing on the CLI
e.g.:
--disk-image path/to/my.disk
would previously fail to find the disk, even if it existed, which is very
counter-intuitive. The following will still fail however:
--disk-image my.disk
which is not ideal, but for now is a comprise between backwards
compatibility of having an M5_PATH and what users expect from CLI
interfaces.
Change-Id: Ic91e1cc20557b35b69490b6dc420e7d324fae1fc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23672
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
All ISAs except SPARC can now take multiple disk images by passing
the --disk-image option multiple times.
Before this patch, several ISAs automatically mounted a secondary disk
called "linux-bigswap2.img", which had to be in M5_PATH even if the end
user did not want more than one disk. This was the case for for example
for X86 but not ARM.
This change was done to:
* allow ARM to have a second disk image in fs.py, which was not possible,
and allow other ISAs like X86 and ARM to take any number of disk images
* provide a simpler, more intuitive CLI interface that does not require
magic disk images to be present in M5_PATH to work for ISAs such as X86.
Linux does not need that secondary image to boot correctly, so it is
more friendly to support a minimal setup that requires the least amount
of binaries to boot, and let supply the second image manually only if
they need it.
* make fs.py --disk-image work more similarly across all ISAs
SPARC was left with a single disk only because its setup was a bit more
complex and would require further testing.
Change-Id: I8b6e08ae6daf0a5b6cd1d57d285a9677f01eb7ad
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23671
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
CNTFRQ_EL0 should be initialised to a uniform value in all cores present
in the system. Previously, this was only done if EL3 was present,
however architecture states CNTFRQ_EL0 may be written from the highest
EL implemented.
This patch moves this initilization outside of the EL3-only one.
Change-Id: Ibaa197de53d531ba898e5137ba4f46a8c9554699
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24683
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Some ABIs (including 32 bit ARM, 64 bit x86) allocate their argument
registers differently depending on their return value. For instance,
if the value needs to be returned in memory because it's too big,
the caller could pass a pointer to where the result should be stored
when the function returns. This pointer acts like an invisible first
argument, offsetting where all the normal arguments actually live.
This change adds a mechanism to handle that case. The Result templates
can now declare an allocate() static method which is given a
ThreadContext *, and a reference to the Position object. It can perform
any adjustment it needs to before the normal argument extraction
starts.
Change-Id: Ibda9095f0e8c9882742d24f5effe309ccb514188
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23747
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
A recent-ish change modified ExeTraceRecord::traceInst to make it more
consistent with DPRINTF-s by using dprintf_flag to print the trace
string. The generated string was passed as the format however, and that
means that all % characters in the output (from register names, for
example) are interpreted as format characters, mangling the output and
making cprintf angry since there are no corresponding arguments.
This change sets the format to "%s" instead, and passes the trace
string as the first argument. The argument won't be parsed for format
specifiers, and so should no longer get mangled.
Change-Id: I8fa9c2c22179a5b55104a618a4af4080a3931c5f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24643
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It looks like this function is supposed to allow you to set up a PC
based event which will trigger when the simulator executes a particular
kernel function. That event doesn't actually do anything, but you can
set a breakpoint there with gdb when debugging gem5 itself.
There are a couple of problems with this function. First, it assumes
that you want to set the breakpoint based on the first system in your
simulation. Frequently simulations have only one system, but there
isn't any rule that says they must, or any way to pick a different
system.
Second, this function assumes that you're in FS mode, that there is a
kernel, and that there is a kernel symbol table to look symbols up in.
On top of that, this function is a bit redundant since you can just use
gdb to debug the kernel inside a simulated system.
Change-Id: I8dadbd42fc7d4ccba2a035a2a72e6ede4b872f3c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24644
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
TheISA::initCPU is basically an ISA specific implementation of reset
logic on architectural state. As such, it only needs to be called if
we're not going to load a checkpoint, ie in initState.
Also, since the implementation was the same across all CPUs, this
change collapses all the individual implementations down into the base
CPU class.
Change-Id: Id68133fd7f31619c90bf7b3aad35ae20871acaa4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24189
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
The build was failing with:
/usr/bin/ld: unrecognized option '--as-needed -fuse-ld=gold'
and --verbose confirms that a single quoted CLI parameter was being
executed:
"-Wl,--as-needed -fuse-ld=gold"
This happened because at Ifb001786a66b0dd9b29865e39a5740313002f250
--as-needed was added, and because it is the second option to happen before
the following main.subst, it exposed the fact that the existing main.subst
was wrong, because it returns a string instead of the expected array.
Change-Id: I619d242d60fe9d27438638ac11c2b92512881f26
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24624
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch adds the reference 32KHz clock to VExpress_GEM5_Base derived
platforms. This is in preparation for supporting the SP805 Watchdog.
I/O voltage domain and platform clock domain coupling is transferred
to the __init__ method for correctness.
Change-Id: Ic743fd986793f1e43b75fa60260c9b43b2737763
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24204
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
A bug has been introduced with the new test url.
The line break should have used a backslash or (this is the recommended
way by PEP8) the implied line continuation via parenthesis.
This error was preventing the test to be loaded with the error message:
Exception thrown while loading
"/tmpfs/src/git/jenkins-gem5-prod/tests/gem5/m5_util/test_exit.py"
Ignoring all tests in this file.
and was not producing a failure (the test was not run: it was jus
ignored).
Change-Id: I0afe252d66d2f6546caaf5e7be811f34f88df82c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24625
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
All of the state being checkpointed would either be provided by the
config directly, or would be brought into the TLB through normal fill
operations. Having this state in the checkpoint complicates the
checkpoint and significantly decreases compatibility with other TLB
implementations, or even variations of the same TLB, for instance if
the size was changed.
Change-Id: I4ea079dd01ff18fbc458b3aaaf88519dbcfdd869
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24389
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The helper is meant to check if the local binary is younger than the
remote binary (on gem5.org). If the call fails it is giving up and
it is just using the local regression (producing a warning).
The code is not handling the blocking behaviour of the connection:
simulaton might stall indefinitely
The patch is addressing this by providing a 10 seconds timeout.
Change-Id: I8f9c2e555c9a55d850a66d02f8e55f56ceda2ca3
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24531
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
