Previously, RISC-V FS support was unable to support O3CPU.
It was due to two issues:
1. CLINT was calling tc->setMiscRegNoEffect which triggers
a conditionalSquash on O3CPU. These frequent squashes led
to assertion error in src/cpu/o3/inst_queue_impl.hh line
1293 (we still suspect that the assertion might contain
some assumptions).
2. A CSR write to SATP needs to trigger a squash (since
MMU can be activated). This is done by conditionally
adding the IsSquashAfter flag to CSR operations if the
target is SATP. This is a simple fix. (Else, an auipc
right after a CSR write to SATP might compute the wrong
value). In the future, a better implementation should
only set the flag for writes to the relevant bit(s).
Change-Id: Ieb9fd0b9aa09e4d2f270b28c2297ea821a81bf65
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43244
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Peter Yuen <petery.hin@huawei.com>
Changes:
1. RiscvBareMetal
The RiscvBareMetal class and API are preserved for backwards
compatibility, but the base class RiscvFSWorkload is removed
as it inherits from the Workload class. However, most needed
functionalities are already implemented in the KernelWorkload
class
2. RiscvLinux
The RiscvLinux class is added. A dtb filename can be specified
to be loaded to the corresponding memory address.
3. HiFive, Clint, Plic, Uart8250, VirtIOMMIO
Devicetree node generation function is added.
4. tlb, faults
Unnecessary includes of arch/riscv/fs_workload are removed.
Change-Id: Ia239b5614bd93d8e794330ead266f6121a4d13cb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42053
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, 2 and 3 levels of indentation, using:
grep -nrE --exclude-dir=systemc \
"^ *union [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>union X ... {
by:
<indent level>union X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc \
"^union [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^union ([A-Za-z].*) \{$/union \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ union [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ union ([A-Za-z].*) \{$/ union \1\n \{/g'
and so on.
Change-Id: I066854eb27a8acd2cc2dfa41596bb1b1f66c71b1
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43328
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, and 2 levels of indentation (and 2 of 2 spaces,
1 of 3 spaces and 2 of 12 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *enum [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>enum X ... {
by:
<indent level>enum X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc \
"^enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^enum ([A-Za-z].*) \{$/enum \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ enum ([A-Za-z].*) \{$/ enum \1\n \{/g'
and so on.
Change-Id: Ib186cf379049098ceaec20dfe4d1edcedd5f940d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43326
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, 2 and 3 levels of indentation (and a single
occurrence of 2 and 3 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *struct [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>struct X ... {
by:
<indent level>struct X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc
"^struct [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^struct ([A-Za-z].*) \{$/struct \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ struct [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ struct ([A-Za-z].*) \{$/ struct \1\n \{/g'
and so on.
Change-Id: I362ef58c86912dabdd272c7debb8d25d587cd455
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39017
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, and 2 levels of indentation, using:
grep -nrE --exclude-dir=systemc \
"^ *class [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>class X ... {
by:
<indent level>class X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc
"^class [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^class ([A-Za-z].*) \{$/class \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ class [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ class ([A-Za-z].*) \{$/ class \1\n \{/g'
and so on.
Change-Id: I17615ce16a333d69867b27c7bae0f4fdafd8b2eb
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39015
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than print the errno, print the result of strerror so the user
doesn't have to look up what each error code does. Don't duplicate
descriptors needlessly which have been returned by pipe(). Use panic_if
instead of if () panic. Check each call to a standard library function
instead of calling multiple and then only knowing that one of them
failed (but not which one). Close the far side of our pipes for both
the gem5 process, and the process that will become diod. Remove some
stray #undef-s which undefine macros that were never defined. Don't
try to force the descriptors going to diod to be particular numbers.
Slightly reduce nesting in the if which checks the results of fork.
Drop unnecessary \n-s in calls to panic, inform, etc. Minor spacing
related style fixes. Use nullptr instead of NULL.
Change-Id: I48d93778a1e139ef624876a0b316486aac774d7f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43083
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The WalkCache stats are wrongly using the legacy framework.
With this patch we are registering those to the hierarchical structure.
As we need to pass the Stats::Group parent at construction time,
we are replacing 2d arrays with Vector2d for count stats and using a flat
vector of pointers for the Formula stats
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I8992bc262a376e4e81a4d608c11dff6902e0a01d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42984
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Added takeover methods for PMA Checker and RiscvTLB to ensure
that checkpoint restoration works. Also added logic in PLIC
to prevent posting interrupts to a CPU that has yet to complete
the current interrupt. PLIC's behaviour when a CPU claims another
interrupt before completion is also changed. Now PLIC will return
the uncompleted interrupt ID instead of return 0. This behaviour
is not documented in the specs but is designed this way to avoid
issues from CPU side (especially MinorCPU).
Change-Id: I68eaaf56d2c4d76cc1e0a1e2160f5abe184c2cd5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41933
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
This function causes problems with gcc 5 which incorrectly complains
about the call to warn_if inside a constexpr function. That should only
be an error if a call to a non-constexpr is unavoidable, and even then
the compiler isn't required to emit a diagnostic.
Rather than drop the warning, or add ifdefs to deal with these defective
versions of gcc, this change eliminates the power() function entirely.
Most inputs to this function would overflow anyway, which is reportedly
why no integer version of an exponentiation function is defined in the
standard library, and all uses of this function can easily and more
efficiently be replaced by simple left and right shifts.
Finally, by eliminating the power() function, we also remove the
dependence on base/logging.hh.
Change-Id: I4d014163883d12db46da4ee752696c8225534ee8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42504
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Like in the nomali library, this bug is in some code making a bitmask
where what bits are enabled depends on some conditions. It used ?: to
evaluate the conditions and | to aggregate the bits, but didn't use any
()s, so the | happened first, then the ?:s. This would generate an
incorrect bitmask.
Change-Id: Iabcc8a9fd38cde5de3c0627a3b143407247c0c0e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40955
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
This patch implements the RISC-V HiFive Platform
(based on the SiFive HiFive series). The HiFive
platform requires a PLIC and CLINT device (based on
current HiFive boards).
The optional uart_int_id field redirects Console interrupts
to the PLIC interrupt controller.
PlicDevice is a wrapper around BasicPioDevice that
requires an interrupt ID. Interrupts are expected to
be raised via platform->postPciInterrupt(id).
VirtIOMMIO is a slight modification from the ARM
implementation such that interrupts are posted through
PLIC
PlicDevice is a wrapper around BasicPioDevice that
requires an interrupt ID. Interrupts are expected to
be raised via platform->postPciInterrupt(id).
VirtIOMMIO is a slight modification from the ARM
implementation such that interrupts are posted through
PLIC.
Uart8250 was modified slightly for easier Python
setup.
Change-Id: I4bbdb5f903b52a41d1b7e0ccc44877c46cd30d56
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40599
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This patch implements the CLINT device model based
on the SiFive U54MC datasheet. CLINT is modelled to
receive its clock signal via an interrupt pin. A
generic RTC (non-MMIO) is also implemented to provide
this signal at arbitrary frequencies.
isa.cc is also modified to provide a correct implementation
of the rdtime instruction. It will read from the miscreg
file (which is updated by CLINT every time mtime is
incremented).
Change-Id: I6f5393f3a8fdbd059f25df51d3d74bcb28da09f1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40597
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The patch is using the newly defined PARAMS macro to replace
custom params() getters in derived class.
The patch is also removing redundant _params:
Instead of creating yet another _params field, SimObject descendants
should use params() to expose the real type of SimObject::_params they
already have.
Change-Id: I43394cebb9661fe747bdbb332236f0f0181b3dba
Signed-off-by: Alexander Klimov <Alexander.Klimov@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39900
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The mismatches were from places where Params structs had been declared
as classes instead of structs, and ruby's MachineID struct.
A comment describing why the warning had been disabled said that it was
because of libstdc++ version 4.8. As far as I can tell, that version is
old enough to be outside the window we support, and so that should no
longer be a problem. It looks like the oldest version of gcc we
support, 5.0, corresponds with approximately libstdc++ version 6.0.21.
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html#abi.versioning
Change-Id: I75ad92f3723a1883bd47e3919c5572a353344047
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40953
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Event creation and management support from emulated drivers is required
to support interruptible signals in HSA and this support was not
available. This changeset adds the event creation and management support
in the emulated driver. With this patch, each interruptible signal
created by the HSA runtime is associated with a signal event. The HSA
runtime can then put a thread waiting on a signal condition to sleep
asking the driver to monitor the event associated with that signal. If
the signal is modified by the GPU, the dispatcher notifies the driver
about signal value change. If the modifier is a CPU thread, the thread
will have to make HSA API calls to modify the signal and these API calls
will notify the driver about signal value change. Once the driver is
notified about a change in the signal value, the driver checks to see if
any thread is sleeping on that signal and wake up the sleeping thread
associated with that event. The driver has also implemented the time_out
wakeup that can wake up the thread after a certain time period has
expired. This is also true for barrier packets.
Each signal has an event address in a kernel managed and allocated
event page that can be used as a mailbox pointer to notify an event.
However, this feature used by non-CPU agents to communicate with the
driver is not implemented by this changeset because the non-CPU HSA
agents in our model can directly communicate with driver in our
implementation. Having said that, adding that feature should be trivial
because the event address and event pages are correctly setup by this
changeset and just adding the event page's virtual address to our PIO
doorbell interface in the page tables and registering that pio address
to the driver should be sufficient. Managing mailbox pointer for an
event is based on event ID and using this event ID as an index into
event page, this changeset already provides a unique mailbox pointer for
each event.
Change-Id: Ic62794076ddd47526b1f952fdb4c1bad632bdd2e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38335
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The thermal models currently work on temperatures in Celsius stored in
plain doubles. Switch to using Temperature instead and internal
processing in Kelvin. There should be no impact on the result since
all thermal processes work on temperature deltas.
Change-Id: I22d0261ae102f30d86051f24a2d88b067b321c91
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39455
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This is a major change in our platform configuration.
At the moment the VExpress_GEM5_V1 and VExpress_GEM5_V2 platforms
both instantiate an HDLcd device. As the presence of the device
can slow down host performances when the software stack is
aware of its presence, we have historically been providing
an entry in the hdlcd DTB node to "hide" the entry from the
DTB parser:
status = "disable";
This default entry in the hdlcd node will in fact prevent the driver
from bringing up the device. Unfortunately this is useful for
experienced users only which are aware of this knob.
In order to make things more transparent, and to avoid any confusion
(e.g. having the hdlcd present in the config.ini, but not being able to
program it in Linux) we are deprecating this solution; we are removing
the HDLcd from the aforementioned platforms.
Users not interested on simulating a display controller won't
notice the difference.
Users interested on including it, will now have to switch to a new
VExpress_GEM5_Vx_HLCD platform
which will enabled the HDLcd without any further tweaking required
JIRA: https://gem5.atlassian.net/browse/GEM5-866
Change-Id: I4b1920efe764080115a57f52d8a3df2e6e2386a0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38796
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
We currently use the traditional SI-like prefixes to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I9b47194d26d71c8ebedda6c31a5bac54b600d3bf
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39575
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We currently use the traditional SI-like prefixes for to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I6ab03934af850494d95a37dcda5c2000794b4d3a
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39578
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When in non-caching mode, performance metrics are not meaningful, and
we're just interested in functional level behavior. Going through the
DMA FIFO in the HDLCD controller is very inefficient, and prevents
reading a batch of pixels from memory all in one go.
Change-Id: I3fb6d4d06730b5a94b5399f01aa02186baa5c9b3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38721
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>