The only functional difference between them was that the SE one might
have optionally fixed up missing translations for demand paging.
This lets us get rid of some code recreating the proxy ports in
setProcessPtr since the SE translating port no longer keeps a copy of
the process object pointer.
Change-Id: Id97df1874f1de138ffd4f2dbb5846dda79d9e4ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26550
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
translateFunctional might be used with unaligned addresses which should
be allowed in that context. Also, in SE mode, if the translation isn't
in the TLB itself, then it should be looked up in the SE mode fake page
tables and not in a page table resident in memory.
Change-Id: Ibb39685cfdcd4eb6cb8a0486a1de014a4e452518
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26831
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This function is no longer used anywhere in gem5.
Small helper functions which had been put alongside vtophys on ARM and
RISCV were also moved into src/arch/arm/remote_gdb.cc and
src/arch/power/pagetable.hh, the only places they were used.
Change-Id: Iba72f6c4b797a35a785a5bb781d602c943541fa7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26234
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are "integer" registers which are renamed, but which aren't
normally considered integer registers by the ISA. They had been indexed
by adding an opaque constant to the number of official integer
registers which obscured what they were, and was also fragile and
invited mistakes.
Change-Id: Idab8cf4d889682b98c7c81a00d9a92d8e3bb3a05
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23445
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Information about what kernel to load and how to load it was built
into the System object and its subclasses. That overloaded the System
object and made it responsible for too many things, and also was
somewhat awkward when working with SE mode which doesn't have a kernel.
This change extracts the kernel and information related to it from the
System object and puts into into a OsKernel or Workload object.
Currently the idea of a "Workload" to run and a kernel are a bit
muddled, an unfortunate carry-over from the original code. It's also an
implication of trying not to make too sweeping of a change, and to
minimize the number of times configs need to change, ie avoiding
creating a "kernel" parameter which would shortly thereafter be
renamed to "workload".
In future changes, the ideas of a kernel and a workload will be
disentangled, and workloads will be expanded to include emulated
operating systems which shephard and contain Process-es for syscall
emulation.
This change was originally split into pieces to make reviewing it
easier. Those reviews are here:
https: //gem5-review.googlesource.com/c/public/gem5/+/22243
https: //gem5-review.googlesource.com/c/public/gem5/+/24144
https: //gem5-review.googlesource.com/c/public/gem5/+/24145
https: //gem5-review.googlesource.com/c/public/gem5/+/24146
https: //gem5-review.googlesource.com/c/public/gem5/+/24147
https: //gem5-review.googlesource.com/c/public/gem5/+/24286
Change-Id: Ia3d863db276a023b6a2c7ee7a656d8142ff75589
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26466
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The version of vtophys which didn't take a ThreadContext had only been
implemented on Alpha which has since been removed, so this version of
the function was completely unimplemented and never used.
This change also gets rid of the dbg_vtophys which was sometimes
implemented but also never used, and takes the opportunity to fix up
some style problems in some of the vtophys arch files.
Change-Id: Ie10f881f8ce08c7188e71805357cf3264be4c81a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26224
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is a slightly munged version of vtophys, but which returns faults
like the normal translate functions if the address is malformed. It
attempts to return an approximately correct fault if the translation
isn't found, but since SPARC doesn't have hardware managed TLBs that
has to be an approximation.
translateFunctional also ignores permissions type checks (unless
they're built into the "lookup" method?) in line with vtophys type
semantics. The idea is that translateFunctional is used in conjunction
with functional accesses, and those are intended to reach beyond
normal barriers/boundaries to give unfettered access to the system for
debugging or setup purposes.
Change-Id: I000d9c31877b82043489792de037e7d664914fa9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26404
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The new local access mechanism installs a callback in the request which
implements what the mmapped IPR was doing. That avoids having to have
stubs in ISAs that don't have mmapped IPRs, avoids having to encode
what to do to communicate from the TLB and the mmapped IPR functions,
and gets rid of another global ISA interface function and header files.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I772c2ae2ca3830a4486919ce9804560c0f2d596a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23188
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
By using braced initializer lists and dropping the default
unimplementedFunc implementation function, the SyscallDesc tables
become a lot less crowded, and it's now very obvious which syscalls
are implemented just by quickly visually scanning the table.
This will also make it a lot easier to change the underlying type
stored in the table without having to adjust all of the instances
within them.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I7821de74812e1c02ca4550fc9c46cc2188cf1bd0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23189
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These don't have anything in them at the moment since making some ISA
methods virtual and not inlined will likely add overhead, specifically
the ones for flattening registers. Some code may need to be rearranged
to minimize that overhead before the ISA objects can be truly put
behind a generic interface.
Change-Id: Ie36a771e977535a7996fdff701ce202bb95c8c58
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25007
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
These two functions were called in exactly one place one right after
the other, and served similar purposes.
This change merges them together, and cleans them up slightly. It also
removes checks for FullSystem, since those functions are only called
in full system to begin with.
Change-Id: I214f7d2d3f88960dccb5895c1241f61cd78716a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24904
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@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>
Endianness transformation was moved from the CPU into this method,
making the "inst" parameter guest endian instead of host endian. The
emi member of the decoder was set using the betoh method, ensuring that
it was still stored in host order. Unfortunately, the "inst" parameter
was used in some places when setting up the rest of emi.
This change replaces those uses of inst with emi.
Change-Id: I0c7f9a1833db4b64fc1a5015cf10f6ba3f7c26a0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23163
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.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>
The first function handles the repetitive process of creating an
ObjectFile for a particular purpose and checking if that was
successful.
The second conditionally offsets the images in case they were, for
instance, loaded from an ELF file which already had them in the right
place. It offsets them so that their entry point (which will be zero
for raw images) lines up with the appropriate entry address (which will
be at the start of raw images).
This is more correct in more cases, and also removes a lot of
redundancy. There's still a lot of redundancy in the code which sets
up the symbol tables, but there are some irregularities which make that
harder to wrap in a helper function.
Change-Id: I2fee8b2175faff284ff9e007307f7769043497a1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21469
Reviewed-by: Brandon Potter <Brandon.Potter@amd.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>
