In the current implementation pollqueue is not thread safe. The design
of multi threads handle async events is thus causing issue in parallel
environment. Given the low rate of async events, it should be OK to only
handle them in the main thread to avoid unexpected racing issues.
Change-Id: Iddd512235e84e9d77f60985bb1771aa4cc693004
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67533
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are the "reset" and "po_reset" lines. It seems reasonable that
these are the normal reset and the power on reset signals, but that's
not spelled out in the fast model "lisa" file, nor does it explain
exactly what the difference is between them.
Change-Id: I686b4d973fc3cfff8a3ec05f8c95ee2cb6ff6698
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67575
Reviewed-by: Jui-min Lee <fcrh@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This CL enables forwarding stream ID from amba_pv to gem5 world.
The stream ID information is originally stored in master_id of
pv::TransactionAtrribute, then it will be stored to m_id of
amba_pv::amba_pv_extension.
This CL brings the information to stream ID field of
Gem5SystemC::ControlExtension. Then the information can be set to stream
ID of the gem5 packet's request.
After bringing the information to gem5, we can identify the packet's
stream ID from gem5 side. One example usage is PL330. In PL330_DMAC, each
transaction is associated with a stream ID. If we can identitfy the
stream ID, we can, for example, set attribute to specific DMAC channel.
Change-Id: I943ce49fde57b0bcfc18b58c7566eec61cc676f4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67591
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
In the previous version, the body of several macros was a statement
(do{...} while(0);) and not an expression. In the new version, all
macros are expressions. Expressions can be used everywhere a statement
is expected and in other locations as well.
For instance, expressions can be used with the comma operator. When
doing generic programming, the comma operator helps manipulating
parameter packs. With a statement-based implementation,
(gem5_assert(args > 0), ...) could not be written while perfectly
sound.
Also, (c1 ? a : c2 ? b : (gem5_assert(c3), c)) is a usefull
expression to assert completeness of cascaded conditions that cannot
be easily and efficiently achieved without an expression kind of
assertion.
Change-Id: Ia0efeb15e6deda6b90529a6f0e00ebe2e9b5d2a0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67336
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
The reference can be bound to an invalid object (*nullptr) in
situations where no proper owner SimObject can be provided to the port
constructor. This rightfully triggers a UBSAN warning.
Also, these two classes do not make use of the owner reference member
themselves and expose it as a protected member reference to
subclasses. This desing has several drawbacks: requires the reference
to owner to travel the class hierarchy up and down, loosing its true
static type in the process ; non-private member variable should not be
part of the API of such fundamental classes, if only for
maintainability ; a reference bound from a nullable pointer is a lying
API as it hides the optional aspect of ownership.
Note that the reference to invalid object can't be properly fixed until
the complete removal of the owner reference. This patch lays the path
toward that fix.
Change-Id: I8b42bc57d7826656726f7708492c43366f20633a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67551
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
safe_cast now supports the exact same types as dynamic_cast would. In
particular, it now supports l-value references and rejects r-value
references.
The non-debug version has also been updated to make it build only in
the same cases as the debug version of safe_cast would.
Change-Id: I86692561c169b1ad063000c990a52ea80c6637ca
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67453
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The only difference between these types in python are the compatibility
strings which restrict what can connect to what. For ports which are
generally useful like interrupts or resets, they should have port types
with special names and even more restrictive compatibility. For other
ports which are one off signals between components, that would be
overkill, and these helpers will let you make a signal port which is
only restricted to ports which carry the same type of data.
The helpers are intended to look similar to their C++ counterpart
templates, and are functions which take a type signature as a string
as their argument, and return a class which is specialized to use that
type signature. The class itself can be stored, or used immediately.
foo = SignalSourcePort('bool')('A port for the foo signal')
Change-Id: If6359b2c69f34ff775cd9aa01272ac487db08bf7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67511
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
As of Linux 5.11, the MC146818 code was changed to avoid reading garbage
data that may occur if the is a read while the registers are being
updated:
github.com/torvalds/linux/commit/05a0302c35481e9b47fb90ba40922b0a4cae40d8
Previously toggling this bit was fine as Linux would check twice. It now
checks before and after reading time information, causing it to retry
infinitely until eventually Linux bootup fails due to watchdog timeout.
This changeset always sets update in progress to false. Since this is a
simulation, the updates probably will not be occurring at the same time
a read is occurring.
Change-Id: If0f440de9f9a6bc5a773fc935d1d5af5b98a9a4b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66731
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The ISA parser now emits the code required to access matrix
registers. In the case where a register is both a source and a
destination, the ISA parser generates appropriate code to make sure
that the contents of the source is copied to the destination. This is
required for the O3 CPU which treats these as two different physical
registers, and hence data is lost if not explicitly preserved.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1289
Change-Id: I8796bd1ea55b5edf5fb8ab92ef1a6060ccc58fa1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64338
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
We add the SME access checks and trapping, which roughly mirrors that
used by SVE.
SME adds a new mode called streaming mode. When a core is in streaming
mode the behaviour of the SVE instructions changes such that they
check the SME traps and enables as opposed to the SVE ones. We
therefore update the existing SVE trap/access checking code to check
the SME equivalents when a core is in streaming mode. Else, the
original behaviour is preserved.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1289
Change-Id: I7eba70da9d41d2899b753fababbd6074ed732501
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64337
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We add the following registers which are added by SME:
* ID_AA64SMFR0_EL1
* SVCR
* SMIDR_EL1
* SMPRI_EL1
* SMPRIMAP_EL2
* SMCR_EL3
* SMCR_EL2
* SMCR_EL12
* SMCR_EL1
* TPIDR2_EL0
* MPAMSM_EL1
In addition we extend some of the existing registers with SME support
(SCR_EL3, CPACR_EL1, CPTR_EL2, CPTR_EL3, etc). These regisers are
responsible for enabling SME itself, or for configuring the trapping
behaviour for the differernt ELs.
In addition we implement some dummy registers as they are officially
required by SME, but gem5 itself doesn't actually support the features
yet (FGT, HCX).
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1289
Change-Id: I18ba65fb9ac2b7a4b4f361998564fb5d472d1789
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64335
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
We add support for the matrix registers to the Arm architecture. This
will be used to implement support for Arm's Scalable Matrix Extension
(SME) in subsequent commits.
We add an implementation of a matrix register for the Arm
architecture. These are akin to 2D vector registers in the sense that
they can be dynamically viewed as a variety of element sizes. As
widening the element size would reduce the matrix size by a factor of
element size, we instead layer multiple tiles of wider elements onto
the underlying matrix storage in order to retain square matrices.
We separate the storage of the matrix from the different views one can
have. The potential views are:
* Tiles: View the matrix as one or more tiles using a specified
element size. As the element size increases the number of indexable
tiles increases. When using the smallest granularity element size
(bytes) there is a single tile. As an example, using 32-bit elements
yields 4 tiles. Tiles are interleaved onto the underlaying matrix
modulo element size. A tile supports 2D indexing ([][]), with the
first index specifying the row index, and the second the column
(element index within the row).
* A Horizontal/Vertical slice (row or a column) of a tile: Take the
aforementioned tile, and extract a specified row or column slice
from it. A slice supports standard []-based indexing. A tile slice
must use the same underlying element type as is used for the tile.
* A Horizontal/Vertical slice (row or column) of the underlying matrix
storage: Treat the matrix register as an array of vectors (rows or
columns, rows preferred due to them being indepependent of the
element size being used).
On simulator start-up the matrix registers are initialised to a
maximum size. At run-time the used size can by dynamically
adjusted. However, please note that as the matrix register class
doesn't know if a smaller size is being used, the class itself doesn't
do any bounds checking itself. This is left to the user.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1289
Change-Id: I6a6a05154846e4802e9822bbbac00ab2c39538ed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64334
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We now explicitly check in both the cache and the MSHRs if writes are
masked or not before promoting to a whole-line write. Failure to do
this previously was resulting in data loss when dirty data was present
in lower level caches and a coincidentally aligned and
cache-line-sized masked write occured.
Change-Id: I9434590d8b22e4d993167d789eb9d15a2e866bf1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64340
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
