| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Iadf56e4e742506af7ae4b617d2dc5a56439aa407
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24188
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This doesn't actually change any behavior since RAX was being zeroed
anyway, but since we don't and almost certainly never will have a BIST
and the BIST is optional even in real hardware, we can drop it and
simplify initCPU a little further.
This reduces x86's initCPU function to just an invocation of
InitInterrupt's invoke.
Change-Id: I56b1aae2c1a738ef7ffabcf648dd7d0fb819d4e0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24187
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
The APIC can (and probably should) set its version register on its
own. Also it already configures its CPUID register when associated
with a CPU and doesn't need initCPU to do that.
Change-Id: I4611563668d197c48caf2f23fcde9ec2ec101fe7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24186
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
The initCPU function was setting a lot of values to zero or other
initial values, but that's something the ISA object can do as part of
its clear() method. This gets rid of a lot of code that was
individually zeroing registers, and also centralizes responsibility
for those registers in the ISA.
Change-Id: Iafcffd3f9329c39f77009b38b1696f91c36c117e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24185
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The granularity bit should be set since the segment limit should be
interpreted as a number of pages, not bytes.
A comment indicates that NX support is enabled, but the bit wasn't
being set. That's now set to be consistent with FS mode.
The SVME bit is now turned off, since Intel CPUs don't have SVME, and
enabling it apparently makes them upset.
Also disable CR4 bits which enable features neither gem5 nor apparently
my workstation support.
Change-Id: I72d5a07871dede8763b0dd188a52fe5eb6bde6ea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23361
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The x86 version doesn't do anything x86 specific, and so can be used
generically in sim/pseudo_inst.(hh|cc)
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I46c2a7d326bd7a95daa8611888051c180e92e446
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23177
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The logic that determines which syscall to call was built into the
implementation of faults/exceptions or even into the instruction
decoder, but that logic can depend on what OS is being used, and
sometimes even what version, for example 32bit vs. 64bit.
This change pushes that logic up into the Process objects since those
already handle a lot of the aspects of emulating the guest OS. Instead,
the ISA or fault implementations just notify the rest of the system
that a nebulous syscall has happened, and that gets propogated upward
until the process does something with it. That's very analogous to how
a system call would work on a real machine.
When a system call happens, the low level component which detects that
should call tc->syscall(&fault), where tc is the relevant thread (or
execution) context, and fault is a Fault which can ultimately be set
by the system call implementation.
The TC implementor (probably a CPU) will then have a chance to do
whatever it needs to to handle a system call. Currently only O3 does
anything special here. That implementor will end up calling the
Process's syscall() method.
Once in Process::syscall, the process object will use it's contextual
knowledge to determine what system call is being requested. It then
calls Process::doSyscall with the right syscall number, where doSyscall
centralizes the common mechanism for actually retrieving and calling
into the system call implementation.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I937ec1ef0576142c2a182ff33ca508d77ad0e7a1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23176
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
|
|
The system call stub KVM uses in SE mode to call the system call
pseudo instruction which ultimately calls m5Syscall already uses
sysret, and the implementation of sysret clears both the RF and VM bits
itself. There's no reason to do that again explicitly here.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: Id7b5417564e3f3492ba6efb8ed36fab2f4c38e09
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23175
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Setting syscall args isn't really something we need to do in gem5,
since that will be taken care of by the code actually calling the
syscall. We just need to be able to retrieve the value it put there.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I0bb6d5d0207a7892414a722b3788cb70ee509582
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23174
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I9bbffcc74ec4f3df4effa5c50f0a4a688c5b6016
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23169
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I5a6db4632ec5b670cbfeb7d52190a7545c0b985f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23380
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Tested with simple c binaries.
Signed-off-by: marjanfariborz <mfariborz@ucdavis.edu>
Change-Id: I2f0852b136f966381d29af523e8ffdbca795afcd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23262
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This conditional compilation was unnecessary and makes gem5 more
brittle and harder to understand.
Change-Id: I63abaf2668252c988cdd4626ff6a462eb6f54b04
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22544
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
These tests assume the "end address" is not included in the range. This
exposed some bugs in addr_range.hh which have been fixed. Where
appropriate code comments in addr_range.hh have been extended to improve
understanding of the class's behavior.
Hard-coded AddrRange values in the project have been updated to take
into account that end address is now exclusive. The python params.py
interface has been updated to conform to this new standard.
Change-Id: Idd1e75d5771d198c4b8142b28de0f3a6e9007a52
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22427
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
These namespaces were used to set up an environment/context where there
was an implicit guest namespace. This is an issue when there may be
multiple guest endiannesses which might be different. In cases where
we don't know what the guest endianness is, we can't rely on it being
an implicit part of our context since that would be ambiguous. In cases
where we do know, for instance in ISA specific code, we can just use
the endianness specific version that's appropriate for that context.
This also (somewhat) removes the assumption that there is a single
endianness that applies for a particular ISA. Practically speaking this
assumption will probably still stand though, since there would likely
be a non-trivial performance penalty to apply a configurable endianness
instead of a fixed one the compiler can optomize/remove.
Change-Id: I2dff338b58726d724f387388efe32d9233885680
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22374
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
We already know what endianness to use from within x86.
Change-Id: Ie92568efe8b23fbb7d9edad55fef09c6302cbe62
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22370
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
It doesn't matter if the bytes are converted before or after they're
fed into the decoder. The ISA already knows what endianness to use
implicitly, and this frees the CPU which doesn't from having to worry
about it.
Change-Id: Id6574ee81bbf4f032c1d7b2901a664f2bd014fbc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22343
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
FLDCW_P and FNSTCW_P should use rip to compute address.
Change-Id: Ide7327e243d42bdd8791e43773385b2a79d45418
Signed-off-by: Zhengrong Wang <seanzw@ucla.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22483
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Change-Id: I5cf4291b19dd2d2bdbbf145ad8e00994fabf5547
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22366
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
That way the syscall implementations won't have to find the right
endianness to use on their own, typically by referring to TheISA.
Change-Id: I186b2f419d5dbee72cc9b5abce7356f3143f0c83
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22363
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
That abstracts the ISA further from the CPU, getting us a small step
closer to being able to build in more than one ISA at a time.
Change-Id: Ibf7e26a3df411ffe994ac1e11d2a53b656863223
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20831
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
It will no longer be a PioDevice or a ClockedObject, but will carry
forward the little bits and pieces of those classes that it was using.
Those are a PIO port for memory mapped register accesses, and a clock
domain parameter for setting the apic tick frequency.
This brings the x86 Interrupts class in line with the Interrupts of the
other ISAs so that they can inherit from a standard base class.
Change-Id: I6b25fa21911b39a756e0cf9408c5489a81d6ca56
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20829
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This code was originally in the ObjectFile class, but not all object
files will become Processes. All Processes will ultimately come from
ObjectFiles though, so it makes more sense to put that class there.
Change-Id: Ie73e4cdecbb51ce53d24cf68911a6cfc0685d771
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21468
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This removes the recvResponse callback from the IntMasterPort, and
makes it easier to handle the default case where we just need to clean
up the Packet.
Change-Id: I8bcbfee0aaf68b12310d773f925c399fc87ea65d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20828
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
|
|
According to the Intel SDM, no instruction following an LFENCE can begin
execution until after the LFENCE has executed. (This is
less strict than an actual serializing instruction, such as CPUID.)
Serializing instructions (per intel SDM Volume 3A Chapter 8.3) ensure
that no future instruction is fetched until after the serializing
instruction is completed.
By contrast, LFENCE (and other memory-ordering instructions) allows
future instructions to have been fetched; it just prohibits them from
being executed.
Change-Id: If89fcb552192326ab69a581f57d71c95cf5d90e7
Signed-off-by: Isaac Richter <isaac.richter@rochester.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/10321
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.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>
|
|
Most of its functionality has been exported already. This change makes
the two classes which were inheriting IntDevice create an IntMasterPort
themselves.
Change-Id: I73d17cd79cf8252b0e26dd2576f552bf9054adf4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20825
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
A memory image can be described by an object file, but an object file
is more than a memory image. Also, it makes sense to manipulate a
memory image to, for instance, change how it's loaded into memory. That
takes on larger implications (relocations, the entry point, symbols,
etc.) when talking about the whole object file, and also modifies
aspects which may not need to change. For instance if an image needs
to be loaded into memory at addresses different from what's in the
object file, but other things like symbols need to stay unmodified.
Change-Id: Ia360405ffb2c1c48e0cc201ac0a0764357996a54
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21466
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The interpreter is a separate object file, and while it's convenient to
hide loading it in the code which loads the main object file, it breaks
the conceptual abstraction since you only asked it to load the main
object file.
Also, this makes every object file format reimplement the idea of
loading the interpreter. Admittedly only ELF recognizes and sets up
an interpreter, but other formats conceptually could too.
This does move that limitted hypothetical redundancy out of the object
file formats and moves it into the process objects, but I think
conceptually that's where it belongs. It would also probably be pretty
easy to add a method to the base Process class that would handle
loading an image and also the interpreter image.
This change does not (yet) separate reading symbol tables.
Change-Id: I4a165eac599a9bcd30371a162379e833c4cc89b4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21465
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The ObjectFile class has hardcoded assumptions that there are three
segments, text, bss and data. There are some files which have one
"segment" like raw files, where the entire file's contents are
considered a single segment. There are also ELF files which can have
an arbitrary number of segments, and those segments can hold any
number of sections, including the text, data and/or bss sections.
Removing this assumption frees up some object file formats from having
to twist themselves to fit in that structure, possibly introducing
ambiguities when some segments may fulfill multiple roles.
Change-Id: I976e06a3a90ef852b17a6485e2595b006b2090d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21463
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
ELF is, in my opinion, the most important object file format gem5
currently understands, and in ELF terminolgy the blob of data that
needs to be loaded into memory to a particular location is called a
segment. A section is a software level view of what's in a region
of memory, and a single segment may contain multiple sections which
happen to follow each other in memory.
Change-Id: Ib810c5050723d5a96bd7550515b08ac695fb1b02
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21462
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@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 IntMasterPort usable with any class, making it possible
to avoid inheriting from IntDevice.
It also makes IntMasterPort inherit directly from QueuedMasterPort,
skipping over MessageMasterPort.
Change-Id: I9d218556c838ea567ced5f6fa4d57a3ec9d28d31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20821
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: 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>
|
|
This will let us accept several address ranges through our pio port
instead of just one, and that will in turn let us accept interrupt
requests and pio requests through the same port.
Change-Id: I70b78c8cd0edca7fe58b3d4cd241e41d9e0f2c20
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20819
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Making the implementation of movntps/movntpd consistent with other
non-temporal instructions. We are ignoring the hint here, and
implementing those instructions as cacheable instructions.
This change adds a warning to let user know about this workaround.
Also, this change add the address check for second part of move.
Change-Id: I811652b24cf39ca2f5c5d4c9e9e417f69190b55c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20408
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Change-Id: I50353716f2a913b9b106b140644d95991879f662
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21039
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Pouya Fotouhi <pfotouhi@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This makes the non-fatal microops advance the PC, and adds missing
functions. The *_once Faults now also can be run once per *something*.
They would previously be run once per Fault invoke function which is
common to all M5WarnOnceFaults. The warn_once microop will now warn
once per message.
Change-Id: I05974b93f3b2700077a411b243679c2ff0e8c2cb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20739
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
We are ignoring the non-temporal hint here, and implementing this
instruction as a cacheable instruction.
This change adds a warning to let user know about this workaround.
Change-Id: I2e40437a44282fe9cf7772a25a8870bd8729a6ed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20428
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Non-temporal quadword/double-quadword move instructions.
This change ignores the non-temporal hint and instructions are
implemented to send cacheable request to memory.
This would have some "performance" impact (i.e. having some cache
pollution) to get better "correctness" in behavior.
Change-Id: I2052ac0970f61a54bafb7332762debcb7103202d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20288
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
xsave is a fairly complex feature which we don't support in gem5, but
we do report that we support it through CPUID. It looks like I confused
it with FXSAVE which is an instruction related to SSE. This change
turns that bit back off again.
Change-Id: I00fc79168c5f7095b5241e870a4c8782e4385425
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20169
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Pouya Fotouhi <pfotouhi@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The previous implementation left the registers unmodified which is
technically correct since there is no defined behavior in that case or
a fault to raise. That would make what happened when the following code
consumed the result unpredictable because it would depend on what junk
values were left in the registers. This was originally not a problem
since the space of supported functions were tightly packed, but someone
added a new function with a gap without adjusting this behavior.
This change makes CPUID zero out RAX, RBX, RCX, and RDX when it fails.
That should be more predictable and cause less flakey failures.
Change-Id: If6ffb17c2969d34aff1600c0ffc32333d0b9be44
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20168
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Pouya Fotouhi <pfotouhi@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The X86 local APIC doesn't actually use the pio_addr set in the config
and instead computes what address it will respond to based on the
initial ID of the CPU it's attached to. gem5's BasicPioDevice, which
the X86LocalApic class inherits from, does not provide a default value
for that parameter and will complain if *something* isn't set. The
value used, 0x2000000000000000, is a dummy value which is the base of
the region of the physical address space set aside for messages to
local APICs from the CPU and from other local APICs.
Also, the clock for the local APIC's timer is defined to be the bus
clock. The assumption seems to be that this has a 16:1 ratio with the
CPU clock, and I vaguely remember finding that that was more or less
unofficially true, even if it isn't necessary stringently defined to
be that.
Since we were already just assuming that that ratio was correct and
always setting up the local APICs clock that way, we can do that in
the X86LocalApic class definition and remove some special x86 specific
setup that we'd otherwise need for the x86 version of the Interrupt
class. If that's not correct, it can still be overridden somewhere else
in the config.
Change-Id: I50e84f899f44b1191c2ad79d05803b44f07001f9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19968
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This changeset adds new (relatively simple) system call
support. The getpgrp call returns a thread context's
pgid.
Change-Id: I361bdbfb9c01b761ddd5a4923d23f86971f8d614
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17111
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
|
|
pipe2 builds on top of the pipe syscall implementation by
adding some extra flags for the files (to avoid have to
make separate calls to fcntl).
Change-Id: I88cf6f1387b9d14e60b33a32db412da9ed93a3e6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12310
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
If a page table walk is squashed, the walker state is being deleted
in the squash code. If there are in flight requests, the deleted
walker state values may be clobbered, leading to undefined behavior.
This adds a squashed boolean to the walker state which is set if a
walk is squashed while requests are still in flight. When packets
for the in flight request return, we check if the walk was squashed
and return that the walk is complete once the number of in flight
requests reaches zero. The walker state is then freed by the PTW.
Change-Id: I57a64b1548b83a8a9e8441fc9d6f33e9842df2b3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19568
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The branch predictor checks whether an instruction is unconditional
branch before adding it or checking the RAS. With this change, the
RAS is significantly more effective for short running x86 workloads.
Change-Id: I60af5f2f583b898ad77f79f4b0478d6cda88fc21
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19448
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
|
|
The movsd instruction should zero out half the register, but
does not do it. This changeset adds the necessary microop to
the instruction to cause correct behavior.
Change-Id: I5278da3634c78a97ed0586f687a36c6dc5a34c60
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19068
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Michael LeBeane <Michael.Lebeane@amd.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
These two functions were performing the same function but had two
different names for historical reasons. This change merges them
together, keeping the getVirtProxy name to be consistent with the
getPhysProxy method used to get a non-translating proxy port.
Change-Id: Idd83c6b899f9343795075b030ccbc723a79e52a4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18581
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
