The O3 model supports unaligned accesses across page boundaries.
This changeset provides a stress test for the feature.
Other benchmarks exercise it, but their coverage is spotty. This
test does nothing else except poke bytes which straddle page
boundaries.
Change-Id: Ic20c2862bcb7af7be091030c12916ba499db10c7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22303
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
This patch was created by Bihn Pham during his internship at AMD.
This patch fixes a very significant performance bug when using the O3
CPU model and Ruby. The issue was Ruby returned false when it received
a request to the same address that already has an outstanding request or
when the memory is blocked. As a result, O3 unnecessary squashed the
pipeline and re-executed instructions. This fix merges readRequestTable
and writeRequestTable in Sequencer into a single request table that
keeps track of all requests and allows multiple outstanding requests to
the same address. This prevents O3 from squashing the pipeline.
Change-Id: If934d57b4736861e342de0ab18be4feec464273d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21219
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If a small number or zero is passed in, fp64_exp could be very
negative (-1000 for example). The intent of the line is to evaluate to
zero in these cases, but what it actually did was bitshift right by
1000, which is undefined behavior (according to ubsan) that so happens
to result in 0 on GCC/most architectures. This commit changes the code
to check for cases where the bitshift is larger than the width of the
integer.
Change-Id: I8de4bd8ad170f0321d54689460de449b7f8fb60a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21859
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This converts the syscall implementations to either use the
OS::byteOrder constant or, if that's not available, the system's
getGuestByteOrder() accessor, to determine the byte order, instead of
relying on TheISA to provide the correct accessor.
Change-Id: Idf7b02ee8d73990224ceac9a5efaec91a5ebf79f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22364
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These classes now track what endianness they're supposed to use
explicitly, initially set by the getGuestByteOrder accessor on the
system object. In the future, if the endianness depends on the
version of the VirtIO spec as the comment suggest, it will be easier
to dynamically set the endianness in the various structures based on
the version being used,
Since there isn't anything special about the virt IO versions of these
converters other than their types, and since the endianness conversion
infrastructure can be taught how to convert new types, the code was
switched over to using the standard htog and gtoh but with the
explicit byte order provided.
This also gets rid of the final use of TheISA in the dev directory.
Change-Id: I9345e3295eb27fc5eb87e8ce0d8d424ad1e75d2d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22273
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
During PCI setup, this patch checks if a Base Address Register (BAR) is
used as a large BAR (64 bits rather than 32), and return proper address
range. The order which updates are done is decided by kernel, so this
patch implements both cases (writing lower or upper bits first).
Bit 2 in a BAR indicates a 64-bit decoder (10X to be more exact, 11X is
reserved).
The addresses in BARAddrs are full addresses and are set to zero for BAR
providing upper 32 bits to avoid conflicts in addr ranges reported.
Change-Id: I93303d36ac83dab9ed6837c81e77c9dfb778f409
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22082
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Current loader is performing a linear scan of the section table for
every segment in the elf since it is naming every segment after the
sections it contains. With this patch we are just naming segments
after their index.
This is in any case how they are referenced when a readelf --segments
command is issued on the elf file.
Change-Id: I599400fcdfc0b80ac64632aba36781bd876777f0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21999
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The code in this #ifdef isn't turned on by anything, and either has or
likely will bitrot, especially since there are no tests to even
determine manually if the code they guard works. They are also
preceeded by panics which say that the code they guard is known not to
work now anyway.
This change also gets rid of TheISA in that file since the only reason
it was around was for vtophys in the guarded code.
Change-Id: I59fd8974d0dd3d7ab0d5a8ccfa6a446d2da41eb0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22265
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are the from the various bits of the tsunami platform. They
primarily consisted of "using TheISA" which could be replaced with
using AlphaISA or removed altogether (I went with the later), and use
of TheISA:: which I replaced with AlphaISA::.
Change-Id: Ic52577c65241a92a3f1ae318a19431f8faa50a66
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22264
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The first function handles the repetitive process of creating an
ObjectFile for a particular purpose and checking if that was
successful.
The second conditionally offsets the images in case they were, for
instance, loaded from an ELF file which already had them in the right
place. It offsets them so that their entry point (which will be zero
for raw images) lines up with the appropriate entry address (which will
be at the start of raw images).
This is more correct in more cases, and also removes a lot of
redundancy. There's still a lot of redundancy in the code which sets
up the symbol tables, but there are some irregularities which make that
harder to wrap in a helper function.
Change-Id: I2fee8b2175faff284ff9e007307f7769043497a1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21469
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Typically, a memory controller is assigned an address range of the
form [start, end). This address range might be interleaved and
therefore only a non-continuous subset of the addresses in the address
range is handed by this controller.
Prior to this patch, the DRAM controller was unaware of the
interleaving and as a result the address range could affect the
mapping of addresses to DRAM ranks, rows and columns. This patch
changes the DRAM controller, to transform the input address to a
continuous range of the form [0, size). As a result the DRAM
controller always operates on a dense and continuous address range
regardlesss of the system configuration.
Change-Id: I7d273a630928421d1854658c9bb0ab34e9360851
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19328
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Wendy Elsasser <wendy.elsasser@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Often a request that hits on an MSHR has to be deferred as it can't be
serviced by the current response.
For example, a request that requires writable has to be deferred when
the response is expected to bring in a read-only copy of the
block. However, there are cases where the response, although not
expected to do so, brings a writable copy and as a result we also
service deferred targets. In such cases, we promote deferred targets
up until the first that can't be serviced by the current response
(e.g., cache maintainance operation). If the first deferred target is
incompatible we don't promote any targets at all.
Change-Id: Ib3e13be51120b7c0f0053b83b76bde03e1b7dd4e
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22127
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The MSHR keeps track of outstanding writes and services them as a
whole line write whenever possible. To do this the outstanding writes
have to be compatible (e.g., not strictly ordered). Prior to this
change, due to this tracking mechanism, the MSHR would not service a
WriteLineReq with flags that do not allow merging as a full line write
even if it was the first target triggering an assertion. This
changeset fixes this bug.
Change-Id: I2cbf5ece0c108c1fcfe6855e8f194408d5ab8ce2
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22126
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
The consolePanicEvent pointer and addConsoleFuncEvent template were
inherited from Alpha and were not used (and probably make no sense) for
MIPS or RISCV which (to my knowledge) don't have the idea of a
"console" binary.
Change-Id: I109b866a65f69c7334062f7304c7b18acc51d99d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21782
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
This was useful when transitioning away from the CPU based
comInstEventQueue, but now that objects backing the ThreadContexts have
access to the underlying comInstEventQueue and can manipulate it
directly, they don't need to do so through a generic interface.
Getting rid of this function narrows and simplifies the interface.
Change-Id: I202d466d266551675ef6792d38c658d8a8f1cb8b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22113
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
