The PC value is put in t7, but for that to be consistent with the way
microcode usually sees and interacts with the PC, it needs to have the
CS base value subtracted from it first. Otherwise the base could be
added into new PC values twice.
Change-Id: I8a8c5bc1befd9a89e6735981fd2fc69a702fdc68
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55690
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
The x86 version is basically just a specialization of the base IO port
version of the QEMU firmware configuration device, with the port
addresses set for x86.
The E820 entry type is x86 specific, and is a way to pass an E820 memory
map to firmware which doesn't have another way to figure out where
memory is. This would be for firmware like SeaBIOS which is itself
responsible for publishing an E820 map, but it needs somewhere to get
that information from in the first place. This mechanism is one it
supports natively.
This entry type reuses the E820Entry SimObjects which were defined a
long time ago for passing to a Linux FS workload. It doesn't use their
ability to write themselves out to guest memory, and just uses them as a
transport for their address, size and type properties.
Change-Id: Ifff214f5fc10bd7d0a2a0acddad4fc00dd65f67d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55628
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Previously, all abstract memory backed by the same physical memory will
use the exact same chunk of shared memory if sharedBackstore is set. It
means that all abstract memories, despite setting to a different range,
will still be map to the same chunk of memory.
As a result, setting the sharedBackstore not only allows our host system
to share gem5 memory, it also enforces multiple gem5 memories to share
the same content. Which will significantly affect the simulation result.
Furthermore, the actual size of the shared memory will be determined by
the last backingStore created. If the last one is unfortunately smaller
than any previous backingStore, this may invalid previous mapped region
and cause a SIGBUS upon access (on linux).
In this CL, we put all backingStores of those abstract memories side by
side instead of stacking them all together. So the behavior of abstract
memories will be kept consistent whether the sharedBackstore is set or
not, yet presist the ability to access those memories from host.
Change-Id: Ic4ec25c99fe72744afaa2dfbb48cd0d65230e9a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57369
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It's possible to bridge together the memory interconnect of two
systems, either as parallel peers, or one nested inside the other. Each
System will have its own set of RequestorIDs, and using an ID from one
System inside the other can lead to a number of different problems.
This change adds a new SimObject called SysBridge which connects two
Systems interconnect together. The object allocates a requestor ID in
each system, and for all PacketPtrs passing through it, the requestor
ID from the target system is installed in the associated Request. On
the way back, either inline or in a split, delayed response, the
original RequestorID is restored by reinstalling the original Request
object.
Change-Id: I237c668962a04ef6dfc872df16762a884c05ede9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54743
Reviewed-by: Jesse Pai <jessepai@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
"resources.json" is referenced when a resource is requested. The
"resources.json" file may be updated at any time and therefore, the
downloader was engineered to retrieve this file from the gem5-resources
repo on each request. However, this can lead to excessively frequently
pulls over short periods of time which is uncessary given how
infrequently this file changes.
To combat this, this patch caches the "resources.json" file and will
use it for up to an hour after creation before re-retrieving it.
Change-Id: I3b4907cbadce8a54df21d85f8021bf3603ae0f6f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57275
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
On occasion HTTP status codes, such as 429, are returned when
downloading the resources and/or the "resources.json" file. In such
cases it makes sense to retry the download.
This patch adds a Truncated Exponential Backoff algorithm to the
downloader to retry downloads, with a default maximum of 6 attempts.
This is done in cases where HTTP status codes 408, 429, and 5xx are
returned.
So this feature is applied to both the retrieval of the resources and
the "resource.json" file, the downloading of the "resources.json" file
has been modified to utilize the `_download` function as is used to
download resources
Change-Id: Ic4444b52f0f71d294fccec9de3140beece5f7576
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57274
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We are introducing the MISCREG_TLBINEEDSYNC misc register to track
the presence of a pending DVM (TLBI) operation.
It will be used by:
* TLBI instructions: setting up the flag to indicate there
is a pending DVM message
* DSB instruction: clearing the flag indicating the DVM
messgage has been syncronized
Change-Id: I7a599ada5a6ac6f86ed2260caa872f085c889ab5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56601
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These correspond to the existing operand types like IntRegOperand, or as
it's called in the operand table 'IntReg'. These subclasses
automatically set the base type name ('IntReg' for IntRegOperands),
which results in some mildly more familiar looking syntax, but is still
not that different from what we have today.
Change-Id: Id77c4e5a5e1b93c10aa9ad85e1a615f6c145832a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49725
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, to specify operands for an ISA, you define a dict from
operand names to properties in the ISA description. The properties are
in a list which has well defined positions for each entry, some of which
are optional.
These lists are fairly opaque since they don't have any way to, for
instance, accept keyword arguments. Also, these specifications simply
list as their first element what type of operand they're going to be.
This change is the first step in turning these specifications into
something more robust like a small temporary object. This object can be
constructed from a class which has a proper constructor that can take
keyword arguments, can have defaults, and can be subclassed.
Change-Id: I5f24d0b41f3e30b24a1ddd10157965d700d6c906
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49724
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This artificial device is provided by QEMU inside their emulated
machines to feed extra configuration information to the system firmware,
or even to the operating system if it chose to use it. The behavior of
this device is explained in the docs/specs/fw_cfg.txt file in the QEMU
source.
This implementation currently supports the traditional interface, and
does not support the DMA based interface, although it probably wouldn't
be that hard to expand it to in the future.
The interface exposes individual entries which can optionally (and
usually) have paths associated with them that you can look up in a
directory type entry which has a fixed index. There are some entries
which are built into the device itself, which are the ID, signature and
directory entries, but the rest can be set up in the config scripts.
To make it easier to add new entries which are not from config scripts,
aka the ones that are hard coded in C++ and built into the device, the
actual entries themselves are not SimObjects, but it's easy to create a
SimObject wrapper which will spit them out for the device to consume.
Other items can be added to the device manually without generating them
with SimObjects.
Entries can have fixed or automatically generated indices. All entries
have a "path" in the sense that they have a name, but as a minor
deviation from what the QEMU documentation says, a "path" which begins
with a "." is not exported in the directory. This is purposefully
reminiscent of the unix style hidden file mechanism, where files or
directories who's names begin with "." are not normally shown by ls.
There are two different styles of this device, one which is IO port
based, and one which is MMIO based. Which to use depends on the
architecture, where x86 currently uses the IO scheme and ARM uses the
MMIO scheme. The documentation doesn't say what other ISAs use, if any
other ones support this interface, but I'd assume the MMIO version.
These are split out because the rules for how they work are subtly
different, but they share a lot of common machinery under the hood.
In most cases where somebody tries to talk to the device in an unusual
way, for instance accessing a register with an incomplete width or at an
offset, the device will just report all zeroes. The behavior in those
cases isn't specified, in many cases doesn't make sense based on the
design of the device, and doesn't seem to be depended on in the limited
use case I looked at.
Change-Id: Ib81ace406f877b298b9b98883d417e7d673916b5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55627
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
This is a far call direct, which has a far pointer (a 16 bit segment
selector and a 16 or 32 bit offset) as an immediate value. The gem5
decoder was expecting no immediate, and so was not gathering one. The
actual microcode for the instruction was taking the junk immediate and
trying to use it which did not work.
This change makes a small update to the table which says how big the
immediate values are for various instructions, changing the entry for
one byte opcode 0x9a from 0 (no immediate) to PO (pointer sized). The
immediate size will be automatically selected by the decoder based on
the PO rule, and the currently active operand size.
Change-Id: Ic290e7bb01dc6165c4eabed214887e4b5adb42da
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55626
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
For all instructions which affect the RIP, they are supposed to
truncate/zero extend the RIP based on the width of the instruction. We
should do that after the target is calculated by adding the two operands
together, but before adding in the segment base address.
Change-Id: I105e58de6a07c7aa3155a9a188d8877c2955651f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55592
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
The stack segment is the default for instructions that use rSP or rBP in
their address calculations at all, except if they're used as a base.
Even though the wording in the AMD manual is a bit misleading, the
presence of a displacement does not make the default DS.
Also, allow segment override prefixes even if the default is SS. If an
instruction *must* use SS (like push or pop) it will have explicitly
specified that in the microcode.
Change-Id: I73c6e367440a664c5c7c483337c16d4ab14f0e34
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55589
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
These methods were all identical, except that IntRegOperand and
CCRegOperand classes had logic to handle operand predication. Since the
other operand types won't have predicates set, we can use the superset
version, and the other types will reduce to what they used to in
practice.
Change-Id: I51eeedcacb7cfc6e2c136742701ee9bf80ec4e15
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49721
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Some ISAs implement TLB invalidation across multiple cores (TLB
shootdown) by broadcasting invalidation messages to every PE in a
target shareability domain.
These messages originate by specific instructions and can be
cathegorized in two macro groups
1) TLB Invalidation instructions: generating the invalidation
request
Example:
* Arm: TLBI instruction [1]
* AMD64: INVLPGB instruction [2]
2) TLB Invalidation sync instructions: serialization point, ensuring
completion of outstanding invalidation requests
Example:
* Arm: DSB instruction [1]
* AMD64: TLBSYNC instruction [2]
This patch is introducing TLBI and SYNC operations in the memory
subsystem by adding the following Request flags:
* TLBI (1)
* TLBI_SYNC (2)
JIRA: https://gem5.atlassian.net/browse/GEM5-1097
[1]: https://developer.arm.com/documentation/ddi0487/gb/
[2]: https://www.amd.com/system/files/TechDocs/24594.pdf
Change-Id: Ib5b025d0f6bc0edaf4f11a66593947a72ba32b8f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56596
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are a number of operand types which are registers. Define a
RegOperand type which they can all inherit from to get register generic
functionality. This will also become a way to add generic register types
with malleable properties at the ISA level.
Change-Id: I01a1d5d133d8f64106d005a744631f64e6808e57
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49719
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
