There are two entities setting up the IOAPIC when the simulation is
started, the IOAPIC itsef, and the PC platform object. It's probably not
a good idea (and definitely confusing) to have this initialization
happening in two places.
For now at least, lets make the PC platform object mask the IOAPIC lines
at startup like the IOAPIC is doing. This will help prevent spurious
interrupts from being delivered to the CPU during startup.
Change-Id: I10f455d8e0fca28ddaf772c224a32c1f5f2dd37b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55452
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are mapped to instruction definitions like MOV_R_R, even though
one or more of the Rs might have come from a fixed value. Because
MOV_R_R (for instance) is only defined once, using a fixed text constant
there won't work because that can only have one value.
Instead, use a variable which will have the value of that constant so
that the same disassembly code will work no matter what fixed value was
used.
Change-Id: Ie45181c6becce80ad44fa30fc3323757ef713d7c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55444
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
This command can trigger count latching for any of the PIT channels
together with a single command, and can also latch a status byte. The
status byte is not implemented here, but there is already functionality
for latching the count which this can use.
Change-Id: Ic2ad7c73d0c521fdd6fe5f62cb478c6718f3b90c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55283
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When performing a real mode far jump, we were computing the offset into
the segment more or less correctly, but then when we tried to actually
set the PC using it, we used the second of the two wrip microop
arguments. The first argument is an unsigned value and is intended to be
a base to work from when figuring out the new IP, and the second
argument is a signed offset which can be used to implement relative
jumps/branches. When we used the second operand for our new value,
setting the first operand to t0 (the zero register on x86), we would
inadvertantly sign extend it since the wrip instruction would treat it
as a signed value.
Instead, we can just switch the two operands so that the wrip microop
treats the desired value as the unsigned base, and then adds a signed t0
to it, which will still be 0 one way or the other.
Also, while researching this bug, I found that the size used for
computing the new IP is always the operand size, and never the address
size. This CL fixes that problem as well by removing the faulty
override.
Change-Id: I96ac9effd37b40161dd8d0b634c5869e767a8873
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55243
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This file populated the "cxx_config_directory" map from type names to
directory entry generating types. It used a comprehensive list of
includes of all SimObject headers, and a comprehensive list of the
generating types to fill everything in.
Instead, this change creates a new singleton helper class which, when
instantiated as a static member of a CxxConfigParams subclass, will
install a pointer to a CxxConfigDirectoryEntry to that map during global
object construction time.
Also, this change renames the map to cxxConfigDirectory which is in
compliance with the style guide, and puts it behind an accessor which
returns a static variable which is the actual map. This avoids any
problems that might come from global object construction order.
Change-Id: Iaa913fbe5af1b11d90ca618e29420eeb7cb0faed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49455
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The BaseCPU type had been specializing itself based on the value of
TARGET_ISA, which is not compatible with building more than one ISA at a
time.
This change refactors the CPU models so that the BaseCPU is more
general, and the ISA specific components are added to the CPU when the
CPU types are fully specialized. For instance, The AtomicSimpleCPU has a
version called X86AtomicSimpleCPU which installs the X86 specific
aspects of the CPU.
This specialization is done in three ways.
1. The mmu parameter is assigned an instance of the architecture
specific MMU type. This provides a reasonable default, but also avoids
having having to use the ISA specific type when the parameter is
created.
2. The ISA specific types are made available as class attributes, and
the utility functions (including __init__!) in the BaseCPU class can
refer to them to get the types they need to set up the CPU at run time.
Because SimObjects have strange, unhelpful semantics as far as assigning
to their attributes, these types need to be set up in a non-SimObject
class, which is then brought in as a base of the actual SimObject type.
Because the metaclass of this other type is just "type", things work
like you would expect. The SimObject doesn't do any special processing
of base classes if they aren't also SimObjects, so these attributes
survive and are accessible using normal lookup in the BaseCPU class.
3. There are some methods like addCheckerCPU and properties like
needsTSO which have ISA specific values or behaviors. These are set in
the ISA specific subclass, where they are inherently specific to an ISA
and don't need to check TARGET_ISA.
Also, the DummyChecker which was set up for the BaseSimpleCPU which
doesn't actually do anything in either C++ or python was not carried
forward. The CPU type still exists, but it isn't installed in the
simple CPUs.
To provide backward compatibility, each ISA implements a .py file which
matches the original .py for a CPU, and the original is renamed with a
Base prefix. The ISA specific version creates an alias with the old CPU
name which maps to the ISA specific type. This way, old scripts which
refer to, for example, AtomicSimpleCPU, will get the X86AtomicSimpleCPU
if the x86 version was compiled in, the ArmAtomicSimpleCPU on arm, etc.
Unfortunately, because of how tags on PySource and by extension SimObjects
are implemented right now, if you set the tags on two SimObjects or
PySources which have the same module path, the later will overwrite the
former whether or not they both would be included. There are some
changes in review which would revamp this and make it work like you
would expect, without this central bookkeeping which has the conflict.
Since I can't use that here, I fell back to checking TARGET_ISA to
decide whether to tell SCons about those files at all.
In the long term, this mechanism should be revamped so that these
compatibility types are only available if there is exactly one ISA
compiled into gem5. After the configs have been updated and no longer
assume they can use AtomicSimpleCPU in all cases, then these types can
be deleted.
Also, because ISAs can now either provide subclasses for a CPU or not,
the CPU_MODELS variable has been removed, meaning the non-ISA
specialized versions of those CPU models will always be included in
gem5, except when building the NULL ISA.
In the future, a more granular config mechanism will hopefully be
implemented for *all* of gem5 and not just the CPUs, and these can be
conditional again in case you only need certain models, and want to
reduce build time or binary size by excluding the others.
Change-Id: I02fc3f645c551678ede46268bbea9f66c3f6c74b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52490
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, an access to an invalid address will cause GEM5 to exit with
a `!pkt.isError()` assertion failure. I was seeing this assertion while
running a baremetal RISC-V binary that faulted before the trap vector
had been configured and therefore tried to jump to address zero. With
this change we now print the invalid address and the type of access
(ifetch/load/store/amo) which makes debugging such a problem much easier.
For example, my faulting program now prints the following:
`panic: Instruction fetch ([0:0x4]) failed: BadAddressError [0:3] IF`
I also saw this assertion with a program that was dereferencing a NULL
pointer, which now prints a more helpful message:
`panic: Data fetch ([0x10:0x11]) failed: BadAddressError [10:10]`
Change-Id: Id983b74bf4688711f47308c6c7c15f49662ac495
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55203
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Port large DS read/write instructions from
https://gem5-review.googlesource.com/c/public/gem5/+/48342.
This implements the 96 and 128b ds_read/write instructions in a similar
fashion to the 3 and 4 dword flat_load/store instructions.
These instructions are treated as reads/writes of 3 or 4 dwords, instead
of as a single 96b/128b memory transaction, due to the limitations of
the VecOperand class used in the amdgpu code.
In order to handle treating the memory transaction as multiple dwords,
the patch also adds in new initMemRead/initMemWrite functions for ds
instructions. These are similar to the functions used in flat
instructions for the same purpose.
Change-Id: Iee2de14eb7f32b6654799d53dc97d806288af98f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55344
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Port the fixes for scalar source checks from arch-gcn3 at
https://gem5-review.googlesource.com/c/public/gem5/+/48344.
Scalar sources can either be a general-purpose register or a constant
register that holds a single value.
If we don't check for if the register is a general-purpose register,
it's possible that we get a constant register, which then causes all of
the register mapping code to break, as the constant registers aren't
supposed to be mapped like the general-purpose registers are.
This fix adds an isScalarReg check to the instruction encodings that
were missing it.
Change-Id: I30dd2d082a5a1dcc3075843bcefd325113ed1df6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55343
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, the test in realview64-simple-atomic-checkpoint.py runs the
default number of checkpoint cycles which is 5. Each of these cycles
takes a long time to run (approximately 5 minutes) which makes this test
take a long time to run to completion. We would get almost all of the
benefit of this test in a fraction of the time if we reduce the number
of iterations down to 3. This still has enough iterations to catch bugs
which would happen in one, a different class of bugs which happen when
checkpointing more than once, and even a third iteration for safety.
Because this test is one of the (if not the) most time consuming test in
the quick tests, reducing its length will significantly improve turn
around time when running all those tests.
That is especially valuable when running the tests multiple times to try
to iterate on a bug, or when sweeping through a series of changes trying
to identify the source of breakages. In cases where we might need to
identify failures which don't effect the end product of a series, ie where
a problem is introduced and then coincidentally fixed in a later change,
this is especially important since every individual change needs to be
checked, not just log(n) of the changes like in a binary search.
Ideally in the future we will also try to figure out why taking and
restoring from checkpoints takes so long so that each iteration of this
test is substantially less expensive. If we do that, we could consider
increasing the iteration count again.
Change-Id: Icfa2a391a4a7457d893f2063fab231d22e572deb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53123
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
When a user accidentally specifies the wrong path to a file, the
following error is received:
```
build/X86/base/loader/image_file_data.cc:111: panic: panic condition fd < 0 occurred: Failed to open file {path}.
```
For new users to gem5 this is confusing, and does not explicitly state
that the root cause of the issue is likely due to the path being
incorrect. Due to use of `panic_if`, this error was followed by a long
and unhelpful backtrace.
This patch expands the error message to state this error is typically
triggered when the specified path is incorrect. It also changes the
`panic_if` to a `fatal_if`. As noted in `src/base/logging.hh`, a
"panic() should be called when something happens that should never ever
happen", while a "fatal() should be called when the simulation cannot
continue due to some condition that is the user's fault". It is clear a
`fatal_if` is more suitable here as it is typically a user error. A
backtrace is not printed for `fatal`, only for `panic`.
Change-Id: I6e0a9bf4efb27ee00a40d77d74fd0dc99f9be4f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55183
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
Add initrd_filename and initrd_addr parameters to specify that an
initrd/initramfs should be loaded into memory from a file, just like the
DTB blob. The user must specify the initrd file, and they can specify
the initrd load address as well. However, in practice, it's expected
that the dev/machine backend will derive the initrd load address from
the dtb load address, which is how a bootloader would typically do it.
Change-Id: I6378927c2984b7ccdd1471486dd7803500ef5883
Signed-off-by: Alistair Delva <adelva@google.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54184
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a new API function, addBootData(), which allows the ports to specify
the size and load address of the initrd/initramfs via DeviceTree. This
uses the standard chosen nodes for initrd-start/initrd-end.
Update the addBootCmdline() to call addBootData() with no
initrd/initramfs so as to maintain backwards compatibility.
Change-Id: I7b1d5cf2a0b18685eaadf1d881434f3d48c45d8b
Signed-off-by: Alistair Delva <adelva@google.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54183
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
