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 SConsopts files that need to be processed is affected by the EXTRAS
setting, and if all settings are going to be local to the variants, that
means each variant can have a different set of SConsopts files to use.
This does result in Configure type output showing up repeatedly when
building multiple variants, but that's uncommon for users, and will
hopefully become unnecessary for developers over time.
Change-Id: I7df287c37fc32e91576dced80d0a9e56806c4581
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56751
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
When powered on, the "passed self test" bit should not be set. It should
only be set once the I8042 has actually been told to do a self test.
Also the mouse and keyboard should be disabled. With them disabled their
interrupts won't matter, but we might as well leave those disabled as
well.
Change-Id: Ief1ab30365a0a8ea0a116e52c16dcccf441515ec
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55805
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The "util/cloudbuild" directory was used to build Docker images on
the Google Cloud Build infrastructure. The gem5 project no longer uses
this service to build Docker images and, as such, this directory (and
its contents) are no longer required.
Change-Id: I724c50ec6045ab95f6b94533f2fd54980230789c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57431
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
"docker-compose.yaml" is used by the docker-compose utility to define
Docker image builds. In the case the "docker-compose.yaml" file defines
the building of all Docker images used in the gem5 project. These can be
built locally using `docker-compose build`.
Change-Id: I2544ec43e3a1743884e5aa243905704cb263d7d9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57429
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When the clone syscall is called, a new process is created which
allocates a new page table. If clone was called with CLONE_THREAD, the
page table of that new process is then marked as shared. Next, initState
is called on the process which calls the page table's initState. For the
multi level page table, initState only sets the base pointer if shared
is false. This means that in this order the base pointer of the new page
table is not currently initialized causing spurious errors.
To fix this, the page table is explicitly initialized after the new
process and new page table are created but before the page table is
marked as shared. The process initState continues as normal and the new
page table's base pointer is not modified by further calls to initState
as it is already marked shared.
Change-Id: I4a533e13565fa572fb9153a926f70958bc7488b7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56366
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@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>
The default MTYPE initialization in the emulated GPU driver is currently
doing a bitwise AND on an input integer param with other integers
instead of using a bitmask. Change this to use bitset and test the bit
positions corresponding to the values in the MTYPE enum that were
previously being used as an operand for bitwise AND.
This was causing invalid slicc transitions in some benchmarks for
combinations of request type and mtype that are undefined.
Change-Id: I93fee0eae1fff7141cd14c239c16d1d69925d08d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56367
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The VIPER configuration uses the MOESI_AMD_Base protocol's directory.
This protocol does not wait for memory ACKs. As a result, this can lead
to read requests being pulled out of the MessageBuffer between the
directory and DRAMCtrl before a write request to the same address. This
leads to inconsistent data. To fix this, make the MessageBuffers
ordered. Since these MessageBuffers are essentially just an interface
between SLICC and DRAMCtrl, and DRAMCtrl can reorder requests properly,
this should not cause any large impact on performance due to the
constraint.
Also remove the duplicate instantiation of these MessageBuffers.
Change-Id: I59653717cc79884e733af3958adfc14941703958
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57411
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This enhances MOESI_AMD_Base-dir DmaWrite to enable partial writes. This
is currently done by assuming a full cache line, invalidating caches,
and transitioning back to unblocked state. The enhanced write supports
partial writes (i.e., smaller than cache line size) by first reading
memory, merging the modified data, and then writing back to memory.
Implementation of this mirrors that of DmaRead in terms of state. This
means for each DmaRead state (BDR_PM, BDR_Pm, and BDR_M) there is a
write analogue (BDW_PM, BDW_Pm, and BDR_M) and the BDR_P state is
removed. Furthermore, this enhanced DmaWrite ... actually writes data to
memory instead of relying on DirectoryEntry / backing store for correct
data.
There are two possible state transitions for DmaWrite now. (1) Memory
data arrives before probe response and (2) probe response arrives before
memory data. In case (1), probe data overwrites memory data and merges
the partial write using the TBE write mask then updates write mask to
'filled' state. In case (2), probe data is merged with the partial data
using the TBE write mask then updates write mask to 'filled' state. The
memory data will then be clobbered by copying the TBE data over the
response since the write mask is now full.
Change-Id: I1eebb882b464c4c5ee5fd60932fd38d271ada4d7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57410
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This protocol is using an old style where read/writes to memory were
being done by writing to a DataBlock in a DirectoryMemory entry. This
results in having multiple copies of memory, leads to stale copies in at
least one memory (usually DRAM), and require --access-backing-store in
most cases to work properly. This changeset removes all references to
getDirectoryEntry(...).DataBlk and instead forwards those reads and
writes to DRAM always.
Change-Id: If2e52151789ad82c7b55c8fa2b41c1f4e5b65994
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57409
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Now that the I8259's vector is reported using a special memory access,
the getVector method doesn't need to be accessible outside of the class.
It's still useful internally though, since it nicely encapsulates what
should happen when an INTA signal is received.
Change-Id: I7da7c1f18fac97ffc62c965978f53fb4c5430de3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55698
Reviewed-by: Gabe Black <gabe.black@gmail.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>
These are no longer split out and shared in the root build/ directory.
This does result in a small amount of overhead from building redundant
copies of these files, although the overhead is not significant. When
building 7 different variants of gem5, all the ISAs and NULL, the
difference on my machine was:
Before:
real 41m25.372s
user 914m22.266s
sys 41m51.816s
After:
real 42m38.074s
user 921m36.852s
sys 43m2.949s
This is about a 2-3% difference, which is a worse than typical case,
since the overhead scales with the number of variants being built.
The benefit of pulling ext/ into the variant directory is that there can
now be a single config which applies to all files used to build gem5,
and that config is represented by the variant of gem5 being built.
Change-Id: I6f0db97c63a7f3e252e7e351aa862340978e701b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56750
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.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>
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>
