This makes what are configuration and what are internal SCons variables
explicit and separate, and makes it unnecessary to call out what
variables to export to C++.
These variables will also be plumbed into and out of kconfiglib in later
changes.
Change-Id: Iaf5e098d7404af06285c421dbdf8ef4171b3f001
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56892
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
For instructions which simply require CPL0 (vs. requiring CPL is < IOPL,
or something else more complicated), this change either switches their
format so that they check that value before being returned, or adds a
comment marking them as privileged if they aren't yet implemented.
This change also makes the mov to/from CR and DR instructions more
particular, and returns an undefined instruction if the CR or DR index
is invalid.
Change-Id: I367d87a380a47428d458bda2ceecc1b983644704
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55891
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This value is already floating around, and there is essentially no
overhead for exposing it to the decoder. With that value, we can handle
instructions which generically need to run at CPL0.
Some instructions have other more complicated permissions checks, like
that the CPL needs to have some relation to the IOPL. Those checks will
have to be implemented by the instructions themselves, since the decoder
can't factor in all possible state values.
Change-Id: Ie93f4f13aae002f69330606c515f369c5706c655
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55889
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This was defined in the Micro_Container base class, and then again in
each subclass. The base definition was different and less complete than
the others, but the others were identical. Replace the base class
definition with the definition in the subclasses, and delete the ones in
the subclasses.
Change-Id: Ib2d1ce72958ec299115efb6efced2bd14c08467c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56330
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Some instructions behave in special ways in virtual 8086 mode. In some
cases, that means that they behave like they do in real mode, even
though the CPU has protected mode enabled. In other cases, it means that
there are extra checks, or even very different behaviors, which help
virtualize the system for the 8086 programs.
Change-Id: I70723b38ea0a7625c4a557bf4dd8f044e5715172
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55809
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The page table walker might need to write back page table entries to set
their accessed bits. It was already checking whether the access was 32
or 64 bit when the PTE was retrieved from the incoming packet, but was
not checking the size when it was written back out, causing an assert to
fail when working with 32 bit legacy PTEs.
Change-Id: I7d02241cad20681e6cac0111edf2454335c466fa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55808
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This pin should be connected to the master I8259 output which is used to
bypass the IOAPIC when it is disabled and the local APIC is in virtual
wire mode. This is how the system is supposed to start, and can later be
switched into symmetric multiprocessing mode later on by an SMP aware OS
(most of them). Only the BSP should have it's LINT0 pin connected to the
I8259, since I8259 type interrupts are only usable by a single CPU at a
time.
Change-Id: I0e3e3338f14d384c26da660cf54779579eb0d641
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55696
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In a real system, once a CPU receives an interrupt of type ExtInt, it
will send an INTA message out to the I8259 sytle interrupt controllers
to read the vector for that interrupt. In ye-olden-times, that would
literally mean the I8259 would be in charge of the bus and would write
the eight bit vector for the CPU to read. In more modern systems, the
vector is transported on the system interconnect using a special
message.
To better approximate a real system, and to make the interrupt
controllers more modular and agnostic (so the IO APIC doesn't have a
I8259 pointer within it, for instance), this change adds a new special
address which the I8259 can respond to on reads which will act as if it
received an INTA message, and the read data will be the interrupt
vector.
Only the master controller, or a single device, will respond to this
address, and because of its value and the fact that it's beyond the end
of the 16 bit IO port address space's effective range but still within
it, that address won't be generated by any other activity other than
possibly a bogus address.
Also by putting the special address in the IO port address space, that
will make it easier to ensure that it's within the range of addresses
which are routed towards the I8259 which operates off the IO port bus.
This address is not yet actually used by the IO APIC or local APIC but
will be shortly.
Change-Id: Ib73ab4ee08531028d3540570594c552f39053a40
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55694
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
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>
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>
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>
When instructions perform accesses, they embed the segment being used
into the request flags. When the CPU creates a request instead, for
instance when fetching an instruction, it doesn't know to do that.
This change adds a check in the TLB when makes sure CS is used when
checking a fetch, even if the flags didn't say to.
Change-Id: Ie9da3afc0b10eeb96247353150c64f1829cea41b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55247
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
