The x86-boot-exit resource is being deprecated for the more versatile
x86-ubuntu-img resource. The latter attempts to run `m5 readfile`,
allowing a user to specify a script to be run. If no script is specified
`m5 exit` is run. Therefore it can be used in the x86-boot-exit tests.
Change-Id: I7fecb314bd0e1d4be4f1181e57046e4621199b64
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50647
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Harris <mail@austin-harris.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The 'components_library' name was always a placeholder. A more accurate
name would be the 'gem5 library'. This is analogous to standard
libraries shipped as part of programming languages. Over time this will
begin to incorporate more commonly used code at the Python configuration
script level. Most of the former 'components_library' is now in
'gem5.components'.
Change-Id: I5927db7004c43b29c39e7767da3f779627081618
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49691
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
There has been some debate on how best to distribute the components
library. This change builds the components library into the gem5 binary.
The components library will now function similar to the `m5` library.
There is no need for awkward imports or obtaining the library from some
third-party source.
Additional incorporated in this patch:
* Added `__init__.py` to the Python modules.
* Fixed a typo in the `abstract_ruby_cache_hierarchy.py` filename.
* Ensured that imports within the library are relative.
Issue-on: https://gem5.atlassian.net/browse/GEM5-1023
Change-Id: I3988c8710cda8dcf7b21109a2cf5c3f1608cc71a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49690
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Austin Harris <mail@austin-harris.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously these scripts were in `configs/example/components-library`
though they are now used purely for testing purposes and have therefore
been moved to `tests/gem5/configs/example/components-library`.
There should be example scripts for usage of the components library, but
these scripts are no longer suitable since being made more flexible for
the purposes of testing.
Change-Id: I7c4d5bb86fe94898f006220dd962841344b1868e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49558
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The Learning gem5 part 3 tests require the building of the X86_MSI
binary. These are the only tests that require this protocol. Building
this is not worth it to just run these tests. They've therefore been
moved to be run nightly rather than as a pre-submit/kokoro test.
Change-Id: If0cdd9c30a160a01cef5fcda8a5433ab2d6ac882
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50027
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change makes three improvements:
1. It uses the gem5 components library
`config/example/components-library/boot_exit_disk_run.py` example. This
test therefore doubles-up as a test for this example and the gem5
components library, as well as full-system x86 booting of Linux.
2. It includes 'very-long' tests to be run weekly. These are a full
cross-product of x86 boot tests and will help identify gem5 failures
more quickly.
3. Quick tests are added to boot the linux OS to a certain tick.
Change-Id: Ie52c267f3382e37912b8ae41dc92b1ee8d06f9f9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49325
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
We have seen cases where the primary CPU was not able to bootstrap the
secondary CPUs in multicore tests (dual). The Linux booting process
"quietly" gives up (no panic) and it completes the booting without
bringing up the seondary CPU(s). This makes the dual test useless as it
is supposed to test SMP setups.
By adding a MatchFileRegex verifier, we make sure we are able to catch
these cases, correctly raising an error if not all CPUs are available.
We do this by inspecting the kernel log for the following print:
"CPU1: Booted secondary processor"
There are probably more resilient alternatives to a regex based check,
but those require a less minimal rootfs (the current
m5_exit.squashfs.arm64 FS has a single /sbin/init binary executing a
simple m5 exit operation)
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I37e0882967443449d5fedfe3963bd25528a030f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44446
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This vestigial device provides a thin layer of indirection between
devices and the CPUs in a system. It's basically a collection of helper
functions, but since it's a SimObject it needs to be instantiated in
python and added to configurations.
Change-Id: I029d2314ae0bb890678e1e68dafcdab4bfe49beb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43347
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If supported this will compress the debug information in object files,
libraries, and binaries. This decreases the size of the build/ARM
directory from 11GB to 7.2GB.
Because the benefit of this mechanism depends on the performance and
capacity of the build machine's storage, it can be disabled with the
--no-compress-debug scons flag. For instance if your storage is very
fast, writing out a larger binary may take less time than compressing
that same number of bytes, plus the time to write out the smaller
file.
This feature seems to make our presubmit test machine run out of memory
when trying to build gem5, and so is disabled in the testing scripts.
Change-Id: I71919062d23742b7658918b0fa9c4d91d0521fbf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40715
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We compile GCN3_X86 for the 'quick' tests, as a substitute for X86. We
compile X86 as part of our nightly tests, along with the running of the
'long' tests. This leads to a needless duplicate compilation of the X86
isa during our nightly tests. Therefore, this commit removes GCN3_X86
for the 'long' tests (only the x86 boot tests are affected).
Change-Id: Ifd8aaf0e7b8178c588ace33b27671d4ba9b353ed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40415
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Inside the code of cloneFunc(…) //syscall_emul.hh
cp->initState(); //line 1483
p->clone(tc, ctc, cp, flags); //line 1484
…
ctc->clearArchRegs(); //line 1503
OS::archClone(flags, p, cp, tc, ctc, newStack, tlsPtr); //line 1505
…
At line 1483, initState() is called and the activateContext() of the
corresponding MinorCPU is eventually called. The actual architecture
clone happens at line 1505 where PC of the new thread could have a
correct value.
In the existing implementation of MinorCPU::activateContext(ThreadID
thread_id), the below line 275 is called
pipeline->wakeupFetch(thread_id);
to start fetching instruction with current value of PC, which is 0x0,
leading to panic “Page table fault when accessing virtual address 0”.
This is because the OS::archClone() is not yet called. So, the below bug
fix handles the wakeup fetch for a thread for two scenarios:
...
if (!threads[thread_id]->getUseForClone())
{ //the thread is not cloned
pipeline->wakeupFetch(thread_id);
} else {//the thread from clone
if (fetchEventWrapper != NULL)
delete fetchEventWrapper;
fetchEventWrapper = new EventFunctionWrapper([this, thread_id]
{pipeline->wakeupFetch(thread_id);}, "wakeupFetch");
schedule(*fetchEventWrapper, clockEdge(Cycles(0)));
}
...
If a thread is not cloned, pipeline->wakeupFetch() is called
immediately.
For the cloned thread, the above bug fix delays the execution of
pipeline->wakeupFetch()
after the OS::archClone is done. ThreadContext::getUseForClone() return
true if a thread is cloned.
A member variable fetchEventWrapper is added to MinorCPU class for
delayed fetch event.
A member variable useForClone and its corresponding get/set methods are
added to ThreadContext class. This approach allows future reuse of this
useForClone variable by other CPU models if needed and also avoid lots
of changes resulted by modifying parameters of activateContext () and
activate() which are defined as override.
Inside the syscall cloneFunc, the useForClone member of a ThreadContext
object is set via its set method right before Process's initState() is
called, shown as below.
ctc->setUseForClone(true);
cp->initState();
p->clone(tc, ctc, cp, flags);
A few previously failed RISC-V ASM tests have been open in tests.py file
after the bug fix works.
JIRA issue: https://gem5.atlassian.net/browse/GEM5-374
Change-Id: Ibffe46522e2617443d29f49df180692c54830f14
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37315
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
