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>
The offset field in Flat-style instructions is treated differently
based on if the instruction is Flat or Global/Scratch.
In Flat insts, the offset is treated as a 12-bit unsigned number.
In Global/Scratch insts, the offset is treated as a 13-bit signed number.
This patch updates the calcAddr function for Flat-style instructions
to properly sign-extend the offset on Global/Scratch instructions
Change-Id: I57f10258c23d900da9bf6ded6717c6e8abd177b7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57209
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
The contextId is generally treated as (and should be) an opaque index
into the System objects threadContext array. When forcing it to
particular values, that introduces gaps in the threadContext array which
trips up other code which is expecting the array to have only valid
entries.
Change-Id: I4997e989b436a3008f65f348722dfb843b2f110a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57089
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
The default constructor for RegId would initialize it with the
IntRegClass and register index 0. This is arbitrary and
indistinguishable from a real ID to the first integer register.
Instead, add a new class type constant InvalidRegClass, and use that to
initialize an otherwise uninitialized RegId.
Also, fill out some enums that needed to handle that value to silence
compiler warnings.
Change-Id: I3b58559f41adc1da5f661121225dbd389230e3af
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49710
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than constantly overwriting the "zero" register to return its
value to zero, just ignore writes to it.
We assume here that the "zero" register is a standard RegVal type
register (ie not bigger than 64 bits) and is accessed as such.
Change-Id: I06029b78103019c668647569c6037ca64a4d9c76
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49709
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are instructions in 64 bit mode which have been turned into the
REX and VEX prefixes, and which should no longer behave as instructions.
When not in 64 bit mode however, those instructions still need to behave
properly.
We were handling that for the REX prefixes by explicitly checking if the
prefix we found was one of those, and then whether we were in 64 bit
mode or not. We were not handling the VEX prefixes at all, so those were
always acting as prefixes, even when not in 64 bit mode.
This change replaces the REX check and possible VEX check by having two
prefix tables, one for 64 bit mode, and one for otherwise. The REX and
VEX prefixes are simply left out of the non 64b it mode table, making an
explicit check for them unnecessary.
Change-Id: Ia2fc17074015e074d1f156177bd499d67da5411d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55587
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
This is essentially the same as the normal one, except it sets its
ProgIF bits to show that it works in compatibility mode only, with fixed
IO ports and fixed IRQs that it operates with which are outside of the
scope of the normal PCI mechanisms.
Change-Id: I69d04f5c9444e7e227588b96b7dd4123b2850e23
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55586
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
This command is one of two that should be implemented by ATAPI devices.
An ATAPI device are essentially optical devices which use SCSI commands
which are transported over ATA using two special commands, a PACKET
command which actually sends the SCSI commands, and an IDENTIFY command
which is basically the same as the ATA IDENTIFY command but which is
only implemented on ATAPI devices. In order to determine if the device
connected to an IDE controller is an optical drive or a regular ATA hard
drive, software can send the ATAPI_IDENTIFY_DEVICE command and see if
gets an appropriate response.
In gem5, this command was originally not implemented by the IDE disk
model. If a driver attempted to send it, the gem5 model would panic and
kill the simulation. To fix that problem, that command was added to the
list of supported commands and just made a synonym for the ATA IDENTIFY
command since they have essentially the same response.
Unfortunately, this makes all ATA devices look like ATAPI devices, which
is not what we have implemented.
Instead, when we get this command, what we *should* do, as far as I can
tell by reading this:
http://users.utcluj.ro/~baruch/media/siee/labor/ATA-Interface.pdf
is to set the ERR bit in the status register, and then set the ABRT bit
in the error register to indicate that the command was not implemented.
I've attempted to implement that into the model with this change by
setting those bits as described, and then setting the "action" member to
be ACT_CMD_ERROR. I think that action is there primarily to support
cancelled transfers, but it seems like it has the desired effect(?).
Since the error bits are not really explicitly set or managed by the
model in most cases, this change also adds a little bit of code at the
top of startCommand which clears them to zero. These bits are supposed
to "contain the status of the last command executed", and if we're
starting a new command, the error bits no longer apply.
I'm confident that conceptually this is how the ATAPI_IDENTIFY_DEVICE
command should behave in our model, at least unless we decide to
implement real ATAPI models which actually accept SCSI commands, etc.
I'm less confident that I've modified the model to actually implement
that behavior, but as far as I can tell it doesn't seem to have broken
anything, and now SeaBIOS no longer things our disk model is a CDROM
drive.
Change-Id: I2c0840e279e9caa89c21a4e7cbdbcaf6bccd92ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55523
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
The stack size is something that applies to addresses when performing
accesses as part of some instructions. This was handled inconsistently
or incompletely or simply incorrectly in a few ways.
First, when pushing or popping from the stack, the *address size* should
be set to the stack size. The data size is generally the operand size.
When the stack pointer is incremented/decremented, it should be changed
by the data size. When a stack pointer is manipulated, the data size
for those calculations should be the stack size. Importantly that does
not change the value of the increment/decrement, which is the operand
size still. This usage has been fixed throughout.
The TLB generally needs to know what the address size was in order to
figure out what segment offset was used so that it can do limit checks.
There is some inherent inaccuracy in doing things in reverse like this,
but that's how it works currently. To find that size, the TLB tried to
start from first principles to figure out what the default address size
was, and then whether there was an override was passed in through the
request flags.
This is *very* inaccurate for a few reasons. First, the override doesn't
always apply. Second, the address size used by a particular instruction
doesn't have to be based on any particular size, whether that is the
default or alternate address size, the stack size, etc.
Instead, the instructions now pass the actual size being used in as a 2
bit value (0 -> 1 byte, 1 -> 2 bytes, 2 -> 4 bytes, 3 -> 8 bytes),
avoiding most of the inaccuracy and approximation.
Because the CPU won't embed any size information into fetches, we'll
just assume those have no wrap around within the address size.
Finally, there were microops that had been added which overrode the
address size to be the stack size internally, and try to help the TLB
figure out what to do to figure out the address size. Because both of
those things are now handled in a different way, those microops are no
longer needed or used and have been deleted.
Change-Id: I2b1bdf1acf1540bf643fac6d49fe1a5a576ba5c1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55443
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
