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>
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>
This patch is pulling the on-chip memory outside of the on_chip_devices
list.
The external interface will be more or less the same: configuration
scripts will still use the attachOnChipIO method; a new kw argument has
been added in order to store mem_ports.
We want to provide to on-chip memory the same mechanism used when
collecting on-chip dma ports. This is needed when using Ruby, since
we need to pass a non None mem_ports to prevent the bootmem to be
wired to the bus.
Change-Id: Ifc519c3072dc5de1530772c70c80dc2094e2c54c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22000
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is carving out a portion of VExpress_GEM5 memory for the
bootloader. Prior to this patch this was only happening
conditionally/dynamically via the setupBootLoader call. With this patch
the region is always present and the setupBootLoader doesn't instantiate
memory, it is only setting up some bootloader parameters.
Change-Id: Iaa5cdf471b14e8faa37353a25631bf7c6fc64afc
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21604
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The devices which host an IntMasterPort are very specific to x86 at the
moment, but the ports don't have to be. This change moves
responsibilities around so that the x86 specific aspects are handled
in the device, and the ports themselves are ISA agnostic.
Change-Id: I50141b66895be7d8f6303605505002ef424af7fd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20827
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There is no interrupt response message, and so no need for a function
which would construct one. The other functions which construct the
request can be consolidated since the work being done by each is
incremental. The template parameters can be used to support multiple
types and offsets in a single function, and since that function also
doesn't have to do much work, it makes sense to do everything in one
shot.
Change-Id: I41b202a263a697c5ada6817f3ab2a4728281b894
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20826
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
When compiling using "scons build/X86/base", "error: 'tx_queue_size'
may be used uninitialized in this function" is received (cc1plus:
all warnings treated as errors). tx_queue_size is now initialized
to zero to avoid this compilation error.
Change-Id: I0e2a4fd9ad6053c4c4124c83da9a7919778bcc52
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21399
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Originally MessageReq was intended to mark a packet as a holding a
message destined for a particular recipient and which would not
interact with other packets.
This is similar to the way a WriteReq would behave if writing to a
device register which needs to be updated atomically. Also, while the
memory system *could* recognize a MessageReq and know that it didn't
need to interact with other packets, that was never implemented.
Change-Id: Ie54301d1d8820e206d6bae96e200ae8c71d2d784
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20823
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
This makes the device IntSlavePort calls back into based on a template
parameter so that IntDevice doesn't have to be in the inheritance
hierarchy to use it.
It also makes IntSlavePort inherit from SimpleTimingPort directly,
skipping over MessageSlavePort.
Change-Id: Ic3213edc9c3ed5e506ee1e9f5e082cd47d7c7998
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20820
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Previous mapping was wrong because it was checking which security bits
it was accessing by using the inSecureState() function, whereas it
should have used the isSecureBelowEL3(). This patch is not making the
sostitution since it is optimizing the mapping furthermore by avoiding
updating both IGRPEN1_EL1 and IGRPEN1_EL3 on writes. The IGRPEN1_EL1
register is used as a storage, and any reads/writes to IGRPEN1_EL3 is
routed to that register.
Change-Id: Id318ec44e19d4f844e4e3410d74d0c4f89810811
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20632
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
