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>
Before this patch, the protobuf builder would search for dependencies
only at the build directory. This works if the importing .proto file
imports paths relative to the build directory, but it results in a build
failure if imports are done relative to the source directory of the
importing file.
This patch adds the source directory of the importing file to the set of
paths searched for dependencies, which solves this issue.
Change-Id: I7debd467485a5087276ac005ac08ab01b32cb02e
Signed-off-by: Adrián Herrera Arcila <adrian.herrera@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55963
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before this patch, the protobuf scanner would detect implicit
dependencies only if the import statement used a path relative to the
build directory. A path with a different format would result in a build
failure.
This is inconvenient because it impedes .proto files within a source
directory to import each other relative to that source.
Moreover, this is critical for EXTRAS directories with .proto files,
because the paths are forced to include the EXTRAS directory itself.
After this patch, the protobuf scanner uses the Classic scanner from
SCons to also detect implicit dependencies in the source path of the
importing .proto file. Regex management is also delegated to the Classic
scanner.
Change-Id: I1ad466813ef44947f3da07371805cb6376e392f0
Signed-off-by: Adrián Herrera Arcila <adrian.herrera@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55903
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In SimpleNetwork, switches were assigned an index depending on their
position in params().routers. But switches are also referenced by their
router_id parameter in other locations of the ruby network system (e.g.,
src and dst node parameter in links). If the router_id does not match the
position in SimpleNetwork::m_switches, the network initialization might
fail or implement a different topology from what the user intended. This
patch fixes this issue by storing switches in a map instead of a vector.
Change-Id: I398f950ad404efbf9516ea9bbced598970a2bc24
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55723
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>
Systemd, which is used by many main stream Linux distributions,
will lead to slow boot if entropy is low. On X86 platforms,
this problem can be alleviated by enabling RDRAND instructions.
However, RISC-V doesn't have similar instructions. For QEMU/KVM,
this problem can be solved by passing randomness from the host
via virtio_rng. But gem5 doesn't have VirtIORng support now.
Some user report that the boot time of riscv-ubuntu-run.py is
too long. To alleviate this problem, this patch add VirtIORng
device support for gem5.
Change-Id: Id93b5703161701212fd6683837034cb0cff590c5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55483
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
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>
Setting the physical_vnets_channels parameter enables the emulation of
the bandwidth impact of having multiple physical channels for each
virtual network. This is implemented by computing bandwidth in a
per-vnet/channel basis within Throttle objects. The size of the
message buffers are also scaled according to this setting (when buffer
are not unlimited).
The physical_vnets_bandwidth can be used to override the channel width
set for each link and assign different widths for each virtual network.
The --simple-physical-channels option can be used with the generic
configuration scripts to automatically assign a single physical channel
to each virtual network defined in the protocol.
JIRA: https://gem5.atlassian.net/browse/GEM5-920
Change-Id: Ia8c9ec8651405eac8710d3f4d67f637a8054a76b
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41854
Reviewed-by: Meatboy 106 <garbage2collector@gmail.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The 'max_dequeue_rate' parameter limits the rate at which messages can
be dequeued in a single cycle. When set, 'isReady' returns false if
after max_dequeue_rate is reached.
This can be used to fine tune the performance of cache controllers.
For the record, other ways of achieving a similar effect could be:
1) Modifying the SLICC compiler to limit message consumption in the
generated wakeup() function
2) Set the buffer size to max_dequeue_rate. This can potentially cut the
the expected throughput in half. For instance if a producer can
enqueue every cycle, and a consumer can dequeue every cycle, a
message can only be actually enqueued every two (assuming
buffer_size=1) since the buffer entries available after dequeue
are only visible in the next cycle (even if the consumer executes
before the producer).
JIRA: https://gem5.atlassian.net/browse/GEM5-920
Change-Id: I3a446c7276b80a0e3f409b4fbab0ab65ff5c1f81
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41862
Reviewed-by: Meatboy 106 <garbage2collector@gmail.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
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>
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>
