| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Al(most) all of the interesting differences between the two classes
have been removed. There are some control methods which are still
specific to each type which may require treating them as their true
type, but most code that consumes them doesn't need to worry about
which is which.
Change-Id: Ie592676f1e496c7940605b66e55cd7fae18e59d6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18577
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
This expands those functions into code which extracts the virt proxy
and then uses the appropriate method on it. This has two benefits.
First, the Copy* functions where mostly redundant wrappers around the
methods the proxy port already had. Second, using them forced a
particular port which might not actually be what the user wanted.
Change-Id: I62084631dd080061e3c74997125164f40da2d77c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18575
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Set the default release to that single value for all ISAs.
glibc has checks for the kernel version based on uname, and refuses
to start any syscall emulation programs if those checks don't pass with
error:
FATAL: kernel too old
The ideal solution to this problem is to actually implement all missing
system calls for the required kernel version and bumping the release
accordingly.
However, it is very hard to implement all missing syscalls and verify
compliance.
Previously, we have simply bumped the version manually from time to
time when major glibc versions started breaking.
This commit alleviates the problem in two ways.
Firstly, having a single kernel version for all versions means that it is
easier to bump all versions at once.
Secondly, it makes it is possible to set the release with a parameter,
which in turn can be set from the command line with:
se.py --param 'system.cpu[:].workload[:].release = "4.18.0"'
Change-Id: I9e3c31073bfe68735f7b0775c8e299aa62b98222
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17849
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Change-Id: Ia73b2d86a10d02fa09c924a4571477bb5f200eb7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18572
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
The page table code must have moved from this class, because
the comment no longer accurately reflects upon any of the
surrounding code.
Change-Id: If08a4298c1237a541d9875ddeaf3d3ecfd98e9db
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12300
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
The system calls had four parameters. One of the parameters
is ThreadContext and another is Process. The ThreadContext
holds the value of the current process so the Process parameter
is redundant since the system call functions already have
indirect access.
With the old API, it is possible to call into the functions with
the wrong supplied Process which could end up being a confusing
error.
This patch removes the redundancy by forcing access through the
ThreadContext field within each system call.
Change-Id: Ib43d3f65824f6d425260dfd9f67de1892b6e8b7c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12299
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Change-Id: I283dd1f52fd020ad3c226eb00fc9216ee034c67f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18630
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This information is used by the LSQ in the O3 cpu (since commit
"51becd2... cpu-o3: O3 LSQ Generalisation")
Change-Id: I35fe7e2f8428641d863af0e79e28b0b259fb0b00
Signed-off-by: Gabor Dozsa <gabor.dozsa@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18508
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Change-Id: I7aeb4fe808d0c8f2fb8041e3662d330d8458f09c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12125
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
|
|
We know for sure what the ISA is, so there's no need for the
indirection.
Change-Id: I73ff04c50890d40a4c7f40caeee746b68b846cb3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18488
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The X86ISA namespace is already available.
Change-Id: I5774968fdfb30b01eba52cdec5e6ef2c75cb66e4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18471
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The AuxVector type has a bunch of accessors which just give access to
the underlying variables through references. We might as well just make
those members accessible directly.
Also, the AuxVector doesn't need to handle endianness flips itself. We
can tell the byteswap mechanism how to flip an AuxVector, and let it
handle that for us.
This gets rid of the entire .cc file which was complicated by trying
to both hide the ISA specific endianness translations, and instantiate
templated functions in a .cc.
Change-Id: I433cd61e73e0b067b6d628fba31be4a4ec1c4cf0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18373
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
These selected their behavior based on ifdefs and had to be disabled
when on the NULL ISA. The versions which take an explicit endianness
have been renamed to just read/write instead of readGtoH and writeHtoG
since the direction of the translation is obvious from context.
Change-Id: I6cfbfda6c4481962d442d3370534e50532d41814
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18372
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
MemObject doesn't provide anything beyond its base ClockedObject any
more, so this change removes it from most inheritance hierarchies.
Occasionally MemObject is replaced with SimObject when I was fairly
confident that the extra functionality of ClockedObject wasn't needed.
Change-Id: Ic014ab61e56402e62548e8c831eb16e26523fdce
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18289
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
That function had a lot of repetition which is easily factored out
into its own function.
Change-Id: I3b7a522de2ba808856bb59df75b80efde6780e3f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18369
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
De-indent the X86ISA namespace, and wrap some overly long lines.
Change-Id: I01a6b66a1cf721e16e4ed4dd1c3469ee112e9177
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18368
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This changeset enables clone to work with X86KvmCPU model, which
will allow running multi-threaded applications at near hardware
speeds. Even though the application is multi-threaded, the KvmCPU
model uses one event queue, therefore, only one hardware thread
will be used, through KVM, to simulate multiple application threads.
Change-Id: I2b2a7b1edb1c56eeb9c4fa0553cd236029cd53f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18268
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Replace the getMasterPort, getSlavePort, and getEthPort functions
with getPort, and remove extraneous mechanisms that are no longer
necessary.
Change-Id: Iab7e3c02d2f3a0cf33e7e824e18c28646b5bc318
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17040
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
TLB:getMasterPort is used to obtain the PageWalkMasterPort if present and
hides the BaseTLB::getMasterPort().
The TLB::getMasterPort() is renamed according to the expected behavior.
Change-Id: If4f61189094a706d59805cd10f4f814e5830eda8
Reviewed-on: https://gem5-review.googlesource.com/c/16648
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
When I try to build x86 architecture and run the se.py sample script
with helloworld example, there is a panic warning stated "Not all stats
have been initialized. You may need to add <ParentClass>::regStats() to
a new SimObject's regStats() function."
I see that in x86 tlb.cc, there is no initialization in regStats() function
that causes memory allocation error in some machine which make gem5 exit
abnormally. I add the BaseTLB::regStats(); on TLB::regStats() method and
can solve the problem
Change-Id: I8b62bebc15f896c3136ff4f8253dabbf998f618f
Reviewed-on: https://gem5-review.googlesource.com/c/16522
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
