The PR contains the following changes:
- Move all of the config options(`env["CONF"]`) from SConsopt to Kconfig
files
- Update `build_opts` files to Kconfig option formats
- The Ruby Protocol files are only built if `RUBY=y`
- Remove the default-default build target
- Kconfig commands are included in the PR:
- defconfig
- setconfig
- meunconfig
- guiconfig
- listnewconfig
- savedefconfig
- oldconfig
- olddefconfig
- Add the `python3-tk` package dependencies
Jira issue: https://gem5.atlassian.net/browse/GEM5-1211
The GPU device keeps a local copy of each ring buffers read pointer
(rptr) to avoid constant DMAs to/from host memory. This means it needs
to be periodically updated on the host side as the driver uses this to
determine how much space is left in the queue and may hang if it believe
the queue is full. For user-mode queues, this already happens when
queues are unmapped. For kernel mode queues (e.g., HIQ, KIQ) the rptr is
never updated leading to a hang.
In this patch the rptr for *all* queues is reported back to the kernel
whenever the queue reaches an empty state (rptr == wptr). Additionally
to handle PM4 queue wrap-around, the queue processing function checks if
the queue is not empty instead of rptr < wptr. This is state because the
driver fills PM4 queues with NOP packets on initialization and when wrap
around occurs.
Change-Id: Ie13a4354f82999208a75bb1eaec70513039ff30f
#525 Updated DRAMSys to v5.0. This PR further improves v5.0
inforporation into gem5 by better managing its new dependencies and
updating the DRAMSys tests to use v5.0.
This PR:
1. Adds a check which throws warning if DRAMSys cannot be build due to a
missing `cmake` instead of failing with a build error. `cmake` is not a
hard gem5 requirement. It is only required to build DRAMSys in the cases
it is required. It is therefore prudent to not fail a build in cases
`cmake` is not present on the host system.
2. Updates the "all-dependency" Docker images to include the optional
dependencies `git-lfs` (needed to clone the DRAMSys repo when running
the command outlined in ext/dramsys/README -- introduced in #525) and
`cmake` (needed to build DRAMSys).
3. Updates the Weekly workflow's `dramsys-tests`' `Checkout DRAMSys` job
to clone DRAMSys in the same manner as outlined in ext/dramsys/README.
This ensures the `dram-systests` test the instructions we give users.
4. `.gitignore` is added to ext/dramsys to ignore the
ext/dramsys/DRAMSys directory when cloned for building and integration
into gem5.
(2.) Should fix our failing weekly tests:
https://github.com/gem5/gem5/actions/runs/6912511984/job/18808339821 and
(3.) will ensure the changes introduced in #525 are tested.
The V_PERM_B32 instruction is selecting the correct byte, but is
shifting into place moving by bits instead of bytes. The V_OR3_B32
instruction is calling the wrong instruction implementation in the
decoder.
This patch fixes both issues plus a bonus fix for GCN3's V_PERM_B32.
(GCN3 does not have V_OR3_B32).
Change-Id: Ied66c43981bc4236f680db42a9868f760becc284
This PR is fixing remaining issues in the ArmISA::Interrupt class; more
specifically it is enabling
virtual interrupts in secure mode (when FEAT_SEL2 is present). Previous
version was assuming no
virtual interrupt was possible in secure mode. We fix this assumption by
replacing the security check
with the EL2Enabled helper which closely matches the Arm pseudocode
This clone is updated to reflect the new advice given in
ext/dramasys/README that was introduced in PR
https://github.com/gem5/gem5/pull/525 to upgrade DRAMSysm to v5.0.
Change-Id: I868619ecc1a44298dd3885e5719979bdaa24e9c2
'cmake' is required to build DRAMSysm.
This is an optional dependency for compiling DRAMSys. It is therefore
not required. It is included in the "all-dependencies" Docker images
as they may be needed if DRAMSys is desired.
Change-Id: I1a3e1a6fa2da4d0116d423e9267d4d3095000d4e
CMake is not required to build gem5. It is only required to build
and link the optional DRAMSysm library. Therefore, if the DRAMSys repo
has been cloned but CMake is not present this patch ensures no attempt
at building or linking DRAMSysm is made. A warning is thrown
inform the user of the missing CMake.
Change-Id: I4d22e3a16655fd90f6b109b4e75859628f7d532d
The config option HAVE_CAPSTONE is added in the previous [1] and
the Kconfig options should be sync with it.
[1] https://github.com/gem5/gem5/pull/494
Change-Id: Id83718bc825f53d87d37d6ac930b96371209bdb3
The CL updates the Kconfig:
1. Replace the USE_NULL_ISA with BUILD_ISA
2. The USE_XXX_ISAs are depends on BUILD_ISA
3. If the BUILD_ISA is set, at least one of USE_XXX_ISAs must be set
4. Refactor the USE_KVM option
Change-Id: I2a600dea9fb671263b0191c46c5790ebbe91a7b8
In gem5, there are many equally valid and equally useful top level
targets which the user might want. It no longer makes sense to
arbitrarily pick one to be the default target. It makes sense to force
the user to actually specify what they want, instead of assuming it
must be the ARM debug binary.
There is currently an M5_DEFAULT_BINARY environment variable which
will change what the default binary is, if set. This change leaves
that in place, but removes the default-default, or in other words the
default that is used if M5_DEFAULT_BINARY is not set.
This way if the user knows what default they want, they can specify it
locally in their environment and avoid having to type it over and over
again, but we're not making an arbitrary choice at a more global level
without the context to know what actually makes sense.
Change-Id: I886adb1289b9879d53387250f950909a4809ed8b
These two utilities help update an old config to add settings for new
config options. The difference between them is that oldconfig asks what
new settings you want to use, while olddefconfig automatically picks the
defaults.
Change-Id: Icd3e57f834684e620705beb884faa5b6e2cc7baa
This helper utility lets you save the defconfig which would give rise to
a given config. For instance, you could use menuconfig to set up a
config how you want it with the options you cared about configured, and
then use savedefconfig to save a defconfig of that somewhere to the
side, in the gem5 defconfig directory, etc. Then later, you could use
that defconfig to set up a new build directory with that same config,
even if the kconfig options have changed a little bit since then.
A saved defconfig like that can also be a good way to visually see what
options have been set to something interesting, and an easier way to
pass a config to someone else to use, to put in bug reports, etc.
Change-Id: Ifd344278638c59b48c261b36058832034c009c78
This helper lists config options which are new in the Kconfig and which
are not currently set in the config file.
Change-Id: I0c426d85c0cf0d2bdbac599845669165285a82a0
This little utility lets you set particular values in an existing config
without having to open up the whole menuconfig interface.
Also reorganize things in kconfig.py a little to help share code between
wrappers.
Change-Id: I7cba0c0ef8d318d6c39e49c779ebb2bbdc3d94c8
This will let you specify *any* defconfig file, instead of implicitly
selecting one from the defconfig directory based on the variant name.
Change-Id: I74c981b206849f08e60c2df702c06534c670cc7c
If you call scons with the fist argument set to menuconfig, that means
to run menuconfig on the path following it. Or in other words, if
you ran this command:
scons menuconfig build/foo/bar
That would tell SCons to set up a build directory at the path
build/foo/bar, and then invoke menuconfig so you can set up its
configuration.
In addition to using this mechanism to set up a new build directory, you
can also use it to reconfigure an existing directory.
This supplements and does not replace the existing mechanism of using
"build/${VARIANT}" to select a config with defconfig.
Change-Id: Ief8e8c2ee6477799455c2004bef06c64be5cc1db
These targets are not necessarily obvious, and tell SCons to do useful
things, like build a particular version of the gem5 binary with a
particular configuration, or run the unit tests.
Add descriptions of these targets to the help so that they are much
more discoverable.
Change-Id: If84399be1a7155ff5f66f511efe1f1c241089c84
This root Kconfig file "source"s (includes) the base gem5 src/Kconfig
file, and also any optional Kconfig files found in the base of EXTRAS
directories. These will be called out in the menuconfig interface and
config files with the name of the EXTRAS directory they came from, and a
blank section will be present either if the Kconfig didn't exist, or it
did exist but had no options in it.
Change-Id: I54060d613f0e0ab9372bed37a2fe5849bf5bbcdb
These are not yet consumed by anything, but convert all the settings
from SCons variables to Kconfig variables.
If you have existing SConsopts files which need to be converted, you
should take a look at KCONFIG.md to learn about how kconfig is used in
gem5. You should decide if any variables need to be available to C++ or
kconfig itself, and whether those are options which should be detected
automatically, or should be up to the user. Options which should be
measured automatically should still be in SConsopts files, while user
facing options should be added to new or existing Kconfig files.
Generally, make sure you're storing c++/kconfig visible options in
env['CONF'][...]. Also remove references to sticky_vars since persistent
options should now be handled with kconfig, and export_vars since
everything in env['CONF'] is now exported automatically.
Switch SCons/gem5 to use Kconfig for configuration, except EXTRAS which
is still a sticky SCons variable. This is necessary because EXTRAS also
controls what config options exist. If it came from Kconfig itself, then
there would be a circular dependency. This dependency could
theoretically be handled by reparsing the Kconfig when EXTRAS
directories were added or removed, but that would be complicated, and
isn't supported by kconfiglib. It wouldn't be worth the significant
effort it would take to add it, just to use Kconfig more purely.
Change-Id: I29ab1940b2d7b0e6635a490452d05befe5b4a2c9
If gem5.build already exists within a directory, then that build
directory can be used without having to worry about variants.
If it doesn't exist and we find a build/${VARIANT} style path, then we
use that as the anchor.
In either case, the variant name is the final component of the build
path. The parse_build_path function had been separating that out, but it
was just put back onto the path again anyway by the only caller, and
then split out again when that path was consumed. We save a step by not
splitting it out in parse_build_path.
Change-Id: I8705b3dbb7664748f5525869cb188df70319d403
The AtomicWait event was not being woken up properly due to the
numPending count in the TBE not being decremented. This patch decrements
the count when Data is returned. Since that moves to a base state, the
TBE should no longer be needed.
Additionally added a transition which stalls and wait when an AtomicWait
occurs while in WI state so that it retries.
Change-Id: Ic8bfc700f9df3f95bea0799121898926a23d8163
When restoring checkpoints for certain applications, gem5 tries to
create new doorbells with a pre-existing queue ID and simulation crashes
shortly after. This commit adds existing IDs to the GPU device's used
VMID map so that new doorbells are aware of existing queue IDs and use a
new ID. This ensures that queue IDs are unique after checkpoint
restoration
The CPU should not sleep with a pending virtual interrupt
if secure mode EL2 is supported (FEAT_SEL2)
Change-Id: Ib71c4a09d76a790331cf6750da45f83694946aee
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Similarly to the physical version [1], we rewrite the
masking logic to account for FEAT_SEL2.
The interrupt table is taken from the Arm architecture reference
manual (version DDI 0487H.a, section D1.3.6, table R_BKHXL)
[1]: https://github.com/gem5/gem5/pull/430
Change-Id: Icb6eb1944d8241293b3ef3c349b20f3981bcc558
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
There is no need to call the methods for every kind
of interrupt. A pending one should short-circuit the
remaining checks
Change-Id: I2c9eb680a7baa4644745b8cbe48183ff6f8e3102
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
With this patch we align virtual interrupts with respect to
the physical ones by introducing a matching takeVirtualInt
method.
Change-Id: Ib7835a21b85e4330ba9f051bc8fed691d6e1382e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Vitual interrupts are enabled in secure mode as well
after the introduction of FEAT_SEL2. Replacing the
secure mode check with the EL2Enabled one
Change-Id: Id685a05d5adfa87b2a366f6be42bf344168927d4
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
https://github.com/gem5/gem5/pull/386 included two cases in
"src/dev/reg_bank.hh" where `std:: min` was used to compare a an integer
of type `size_t` and another of type `Addr`. This causes an error on my
Apple Silicon Mac as the comparison between an "unsigned long" and an
"unsigned long long" is not permitted. To fix this issue this patch
changes `reg_size` from `size_t` to `Addr`, as well as it the types of
the values it was derived from and the variable used to hold the return
from the `std::min` calls. While not completely correct typing from a
labelling perspective (`reg_bytes` is not an address), functions in
"src/dev/reg_bank.hh" already abuse `Addr` in this way frequently (for
example, `bytes` in the `write` function).
When restoring checkpoints for certain applications, gem5 tries to
create new doorbells with a pre-existing queue ID and simulation crashes
shortly after. This commit checkpoints the existing VMID map so that any
new doorbells after restoration use a unique queue ID
Change-Id: I9bf89a2769db26ceab4441634ff2da936eea6d6f
https://github.com/gem5/gem5/pull/386 included two cases in
"src/dev/reg_bank.hh" where `std:: min` was used to compare a an integer
of type `size_t` and another of type `Addr`. This cause an error on my
Apple Silicon Mac as this is a comparison between an "unsigned long"
and an "unsigned long long" which (at least on my setup) was not
permitted. To fix this issue the `reg_size` was changed from `size_t` to
`Addr`, as well as it the types of the values it was derived from and
the variable used to hold the return from the `std::min` calls.
Change-Id: I31e9c04a8e0327d4f6f5390bc5a743c629db4746
This dockerfile is used to *build* applications (e.g., from
gem5-resources) which can be run using full system mode in a GPU build.
The next releases disk image will use ROCm 5.4.2, therefore bump the
version from 4.2 to that version.
Again this is used to *build* input applications only and is not needed
to run or compile gem5 with GPUFS. For example:
$ docker build -t rocm54-build .
/some/gem5-resources/src/gpu/lulesh$ docker run --rm -u $UID:$GID -v \
${PWD}:${PWD} -w ${PWD} rocm54-build make
Change-Id: If169c8d433afb3044f9b88e883ff3bb2f4bc70d2
When restoring checkpoints for certain applications, gem5 tries to
create new doorbells with a pre-existing queue ID and simulation crashes
shortly after. This commit adds existing IDs to the GPU device's used
VMID map so that new doorbells are aware of existing queue IDs and use a
new ID. This ensures that queue IDs are unique after checkpoint
restoration
Change-Id: I9bf89a2769db26ceab4441634ff2da936eea6d6f
