The recent change to add an "exclude" pattern to Glob in SCons also
seems to have triggered a bug where SCons has decided directories that
don't exist are files, and then gets upset later when we try to treat
them as directories.
To avoid that bug, and to also make recursive searching for isa parser
.py files work, we can replace the call to Glob with a loop based on
os.walk.
Also, tell the microcode assembler not to generate the parsetab.py file
in the first place. This comes with a minor performance overhead, but
shouldn't matter for us since there are *much* bigger overheads when
processing ISA descriptions.
Change-Id: Ia84e97dab72723ad3f4350798ad70178e231144c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56749
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
When instructions perform accesses, they embed the segment being used
into the request flags. When the CPU creates a request instead, for
instance when fetching an instruction, it doesn't know to do that.
This change adds a check in the TLB when makes sure CS is used when
checking a fetch, even if the flags didn't say to.
Change-Id: Ie9da3afc0b10eeb96247353150c64f1829cea41b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55247
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When dealing with segmentation in x86, it is *usually* illegal to
attempt to access a segment which has a null selector when in protected
mode and not in 64 bit mode. While this is *almost* true, it is not
actually technically true.
What actually *is* true is that if you *set up* a segment using a null
selector in those circumstances, that segment becomes unusable, and then
tryint to use it causes a fault.
When in real mode, it is perfectly legal to use a null selector to
access memory, since that is just a selector with numerical value 0.
When you then transition into protected mode, the selector would still
be 0 (a null selector), but the segment itself would still be set up
properly and usuable using the base value, limit, and other attributes
it carried over from real mode.
Rather than check if a segment has a null selector while handling
segmentation, it's more correct for us to keep track of whether the
segment is currently usable and check that in the TLB.
Change-Id: Ic2c09e1cfa05afcb03900213b72733545c8f0f4c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55245
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
These were loading the immediate into a temporary microcode register
which would then be used to calculate the address to actually send to
the memory system. Unfortunately this was using a data size equal to the
address size, which would mean that the immediate would be merged into
that temporary, leaving previously set bits intact. The data size
*should* have been set to 8, and was already in other similar
instructions. That forces the limm microop to overwrite the temporary
entirely.
Change-Id: I87c82b4677db768ccb6401a3dbda61317c014152
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55286
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Because we don't have a good way to actually figure out what python
files we depend on, we have to use Glob and wildcard matching to depend
on all potential python files. Unfortunately that will pick up the
parsetab.py file that ply generates, which is a cached intermediate file
and not an input.
Change-Id: Id3dc0083e97c145deca04939182157623d6b780f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56341
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
According to KVM Docs [1]:
"When KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 is supported, the target vcpu is
identified as (256 * vcpu2_index + vcpu_index). Otherwise, vcpu2_index
must be zero."
The vcpu parameter from the setIntState method is populated with
the gem5 context identifier (ContextID) of a specific PE.
It is not contrained by the 256 vcpu limit, so it can already specify
more than 256 vcpus. We therefore just need to translate/unpack the
value in two indices (vcpu and vcpu2) which will be forwarded to KVM
when raising an IRQ from userspace.
We guard the vcpu2 retrieval with a hash define as this is a late
addition and some older kernels do not define this capability (4.15 as
an example).
[1]: https://www.kernel.org/doc/html/latest/virt/kvm/api.html
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: If0c475dc4a573337edd053020920e9b109d13991
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55964
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
During the page table walking,
MMU will perform the PMP check for each page table page.
However, in the current implementation,
the param:mode used by pmp_Check() is equal to the MMU mode,
which means the page table page has an executable mode
if the target page is executable (during pmp_Check).
As the page table page will never be executable,
the mode for the page table page is either read or write.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1143
Change-Id: I105f52ef58fe1fbbf7d84c6563e8a8c22cea9ccb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55063
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
The near call instruction first attempts to store the return address on
the stack (the part of the instruction that could fail), and then if
that succeeds it decrements the stack pointer to point at the newly
stored data.
Unfortunately, the microcode was not using the same offset between
those two steps. Specifically it was using the effective operand size
when storing the return address, but then incorrectly using the
effective stack size when adjusting the stack pointer.
This change updates the microcode to use the effective operand size in
both places.
Change-Id: Ic4211a96900fee5d10c2fa0e038070383fefaac3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55250
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
By default, registers are the size of RegVal, the type often used to
store them. For some types of registers, like vector or vector predicate
registers, the size of each individual register is larger, and can't fit
in a primitive type.
To help facilitate storing even these outliers in a generalized way,
this change adds two fields to RegClassInfo to track the size of
individual registers. One tracks the raw size of the registers
themselves, and the other tracks the minimal shift necessary to find the
offset of a register in a contiguous(ish) array of bytes. By forcing
each register to be aligned to a power of two boundary, we avoid having
to do a multiplication to find their address even if the registers are
oddly sized. We can instead do a shift with a precomputed shift amount
which should be faster.
Change-Id: I035f1b4cb00ece4e8306d7953ea358af75a0d1de
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49104
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The KvmVM will declare itself to the System object, instead of the other
way around. This way the System object can just keep an opaque KvmVM
pointer which does not depend on the KvmVM code even being compiled into
gem5. If there is a KvmVM object, that can more safely assume there is a
corresponding System object to attach itself to.
Also move use of the KvmVM pointer out of constructors, since the VM may
not have registered itself with the System object yet. Those uses can
happen in the init() method instead.
Change-Id: Ia0842612b101315bc1af0232d7f5ae2b55a15922
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56187
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The GICv3 register interface is different from the GICv2 one: from
the presence of redistributor registers up to the system register
implementation of the cpu-interface
We therefore make the current BaseGicRegisters interface GICv2 specific.
We will define a different Gic3Registers interface for GICv3 state
transfer
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I42f15f48cab6e26aaf519e13c2ce70f661801117
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55703
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
De-virtualize updateIntState and replace it with the new blockIntUpdate
in the MuxingKvmGic class.
The monolithic updateIntState is GicV2 specific and it is not compatible
with the more complex IRQ update logic in GicV3, which is delegating the
update to the destributor/redistributor/cpuinterface classes
Rather than stubbing the update function the MuxingKvmGic class, we
override the blockIntUpdate to return true in case a KVM gic is in use.
This is loosening the interface, not restricting any GIC implementation
to a specific update interface/design
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: Ib8d9c99b720c779a2255ac47ee2a655ff281581d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55609
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously calling a function with an INT_MAX argument would result in
the following (incorrectly extended) trace:
```
lui a1, 524288 : IntAlu : D=0xffffffff80000000
c_addiw a1, -1 : IntAlu : D=0xffffffff7fffffff
```
I noticed this due to a kernel assertion that checked the second argument
was bigger than the first. Since INT_MAX was incorrectly being extended to
0xffffffff7fffffff, the generated slt comparison instruction was returning
1 instead of the expected zero (which would have happened with 0x7fffffff).
The problem in the current addiw logic is that the immediate value is an
int64_t, so the 32-bit Rs1/Rc1 values are promoted to 64-bit for the
aritmetic operation, thereby making the current cast redundant.
Fix this by placing parens around the whole expression and truncating
that to 32 bits.
Change-Id: I7b18a8101b1c2614b9f056004e6a7f87b66b64c9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56103
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These registers used to be accessed with a two dimensional index, with
one dimension specifying the register, and the second index specifying
the element within that register. This change linearizes that index down
to one dimension, where the elements of each register are laid out one
after the other in sequence.
Change-Id: I41110f57b505679a327108369db61c826d24922e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49148
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Global instruction address calculation when using an SGPR or SGPR pair
as a base address was being calculated incorrectly when 64-bit addresses
were to be generated.
From the ISA documentation, the SGPR should be read as 32-bit or 64-bit
depending on "ADDRESS_MODE." The VGPR-offset (computed from the lower
32-bits of vaddr) should always be 32-bits and the offset is 12 bits
from the instruction. This means the 32-bit mask should only be applied
to vaddr to get the VGPU-offset rather than the final sum.
The SGPR base format is being seen in more recent clang/ROCm versions to
avoid unnecessary copies of SGPRs into VGPRs to use VGPRs as the base
address.
Change-Id: I48910611fcfac5b62bc63496bbaabd6f6e53fe0d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55643
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The 7th parameter of breakpoint_set_code is dontStop. It seems the
fastmodel would prefetch something or do some evaluation ahead with the
flag set. This behavior prevents the instruction stepping feature of
gdb. The implementation of the feature is creating a breakpoint on the
next instruction and contining the simulation. Without stopping on the
breakpoint, it wouldn't invoke the breakpoint callback, since it may
evaulate the code we just want it to stop already. We should set the
dontStop to false to fix this issue.
Change-Id: Iaf8acd3235fa9625c1423ef34606e1fa5d0c531a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55484
Reviewed-by: Earl Ou <shunhsingou@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Ported from https://gem5-review.googlesource.com/c/public/gem5/+/48019:
Certain DS insts are classfied as Loads, but don't actually go through
the memory pipeline. However, any instruction classified as a load
marks its destination registers as free in the memory pipeline.
Because these instructions didn't use the memory pipeline, they
never freed their destination registers, which led to a deadlock.
This patch explicitly calls the function used to free the destination
registers in the execute() method of those Load instructions that
don't use the memory pipeline.
Change-Id: I8231217a79661ca6acc837b2ab4931b946049a1a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55463
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
