This function is based off of vtophys in the full system case, and off
of the page table fill mechanism used in SE mode. It ignores what's
already in the TLB, and also ignores protection mechanisms.
This may need to be reworked in the future if, for instance, pages
still resident in the TLB but not in the page tables need to be
considered, but it should work at least for the time being.
Change-Id: If21701ca36a30805f4199312933a8afc91f20501
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26405
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
All over gem5 the params pointers are not deleted within the classes
that they were created for. Although this is a potential memory leak
as of now, it is probably safer to follow general convention so that
it can be fixed at once in the future.
Change-Id: If96f04058d51513fa8763610880e5524785ee9cf
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24249
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
All over gem5 the params pointers are not deleted within the classes
that they were created for. Although this is a potential memory leak
as of now, it is probably safer to follow general convention so that
it can be fixed at once in the future.
Change-Id: I74b662a8e635cdfb4dc1eae732dd114659fab2e9
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24246
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
My new computer has a dynamic linker which seems to use the pread64
system call, and since that gets pulled in when running tests, that
needs to be implemented for tests to pass on that machine, making it
possible to detect problems the failure might ohterwise mask.
This is only really necessary for 64 bit linux, but while I'm here I
hooked it up for 32 bit linux as well. I also added pwrite64 for 32 bit
linux since that was only enabled for 64 bit.
Change-Id: I8d2061d30e98a1581c5e30b522b6ba12aea20ecd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26604
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Since I02919207d6f175854017ae7b603d811da63d618e the fs.py --bootloader
option can be used to select a bootloader explicitly.
Ia3d863db276a023b6a2c7ee7a656d8142ff75589 forgot to pass that parameter
likely due to a rebase issue and it gets searched in M5_PATH.
Change-Id: Ic4cf3ccf041e1c34eac7753424fe842bd34a77f9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26724
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Python 3 uses the concepts of two different types:
text and binary strings.
Those cannot be implicilty combined (as it was happening in python2) and
in order to be used together one of them must be converted to the other
type:
* Text can be encoded into Bytes via the encode() method
* Bytes can be decoded to Text using the decode() method
By default encode/decode will assume UTF-8 format
JIRA: https://gem5.atlassian.net/browse/GEM5-345
Change-Id: I1bdf7db17b49cc109239fd5f44791769370853f8
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26250
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
* dict methods dict.keys(), dict.items() and dict.values()
return "views" instead of lists
* The dict.iterkeys(), dict.iteritems() and dict.itervalues()
methods are no longer supported.
* map() and filter() return iterators.
* range() now behaves like xrange() used to behave, except it works with
values of arbitrary size. The latter no longer exists.
* zip() now returns an iterator.
Change-Id: Id480018239db88d7f5d60588c93719056de4a0c0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26248
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In case a workload is run with no bootloader we still want to be able
to provide the simulation with the correct arch version.
Without this patch every baremetal simulation will default to AArch64, which
is the default value of ArmFsWorkload.
Change-Id: I0f766167d8983cafc1fd30d054862339eb21f73f
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26606
Reviewed-by: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
While the up-to-date data may reside in any agent of Ruby's memory
hierarchy, there's an optional backing store in Ruby that provides
a 'correct' view of the physical memory. When it is enabled by the
user, every Ruby memory access will update this global memory view
as well upon finishing.
The issue is that Ruby's atomic access, used in fast-forward, does
not currently access the backing store, leading to data
incorrectness. More specifically, at the very beginning stage of the
simulation, a loader loads the program into the backing store using
functional accesses. Then the program starts execution with
fast-forward enabled, using atomic accesses for faster simulation. But
because atomic access only accesses the real memory hierarchy, the CPU
fetches incorrect instructions.
The fix is simple. Just make Ruby's atomic access update the backing
store as well as the real physical memory.
Change-Id: I2541d923e18ea488d383097ca7abd4124e47e59b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26343
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Onur Kayıran <onur.kayiran@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This flag makes constructing a generic Request object for ARM
impossible, since generic consumers won't know to set that flag to one.
As a principle, Request flags should change the behavior of a request
away from whatever the default/typical behavior is in the current
context, so flags set to zero means no special behavior.
Change-Id: Id606dc0bf42210218e1745585327671a98a8dba4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26546
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is a reduced model of the FVP Base platforms Power Controller.
As of now it allows the following functions from software:
- Checking for core presence
- Reporting the power state of a core / cluster
- Explicitly powering off a core on WFI
- Explicitly powering off cores in a CPU cluster on WFI
- Explicitly powering on a core through writes to PPONR register
Change-Id: Ia1d4d3ae8e4bfb2d23b2c6077396a4d8500e2e30
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26463
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This method can be used for allocating resources for registers and/or
arguments, but it can also be used for generic preparation for them
as well. For instance, it can be used to detect some sort of property
of the function signature as a whole (if it's variadic for instance)
which can be stored in position and used to change ABI behavior.
Change-Id: I8a090be65dc4987e35cd115562114cd1b748155f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24106
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This header was getting pretty long, and could be broken up into a few
headers which logically grouped related definitions and concepts.
To maintain compatibility and keep things simple for users of the
mechanism, there is still a top level header with the original name
which defines the interface for using ABIs. It includes all the other
new headers, and so can also be used when defining ABIs.
Change-Id: I62a051b9bd982e0fcecfceeb3d658d1ff4d30c5e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24104
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
This change generalizes the GuestABI Result template family's
allocate() mechanism so that it can also be used with arguments. This
is useful in cases like the 32 bit ARM ISA which says that variadic
functions treat their floating point arguments differently than
non-variadic functions do. This mechanism will give the ABI a chance
to detect that the function is variadic (by checking for VarArgs) and
then to behave differently in that case.
This also makes the GuestABI mechanism a little more regular by
supporting allocate() on both arguments and return values instead of
just return values.
Change-Id: I67050a0ad7ccf15ee75b800dca4eae4fdc0e564e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24103
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
This implementation has been tested a tiny bit by intercepting a call
which passed an argument of this type to a function.
struct Test
{
int32_t a;
float *b;
};
The gem5 intercept printed out the value of a, the value of b, and the
value of the float it pointed to.
I was able to get things to work by commenting out the panic in
fixFuncEventAddr and making it return its argument unmodified, and by
calling addFuncEvent instead of addKernelFuncEvent which injects the
kernel symbol table. I substitured the Process's debugSymbolTable which
had the right symbols.
Note that this implementation is not completely correct. First of all,
I used a dummy type in place of the Short Vector type which is just
a byte array with the appropriate alignment forced on it. It sounds
like this type would be something the compiler would need an intrinsic
and architecture specific type for to behave correctly, and so in
gem5 we'd have to define our own type for ARM which could feed in here.
Also, strictly speaking, it sounds like HVA and HFA category of types,
the Homogeneous Short-Vector Aggregates and Homogeneous Floating-point
Aggregates, are supposed to apply to any type which is an aggregate of
all the same type (short vector for one, floating point for the other)
with 4 or fewer members.
In this implementation, I capture any *array* of 4 or fewer elements of
the appropriate type as an HVA or HFA, but I believe these structures
would also count and are not included in my implementation.
struct {
float a;
float b;
float c;
};
struct {
ShortVector a;
ShortVector b;
};
This only matters if those sorts of structures are passed by value as
top level arguments to a function, ie they are not included in some
larger structure.
Also, rule B.6 talks about what to do with an "aignment adjusted type",
and I have no idea what that's supposed to be. Those may not be handled
correctly either.
Change-Id: I5a599a03d38075d7c0a06988c05e7fb5423c68c0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23751
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
The pseudo instruction implementation is very short, and so doing the
work it was doing directly doesn't really add much to the
implementation of the udelay events. By not calling the pseudo
instruction we also uncouple these unrelated mechanisms and don't,
for instance, cause pseudo instruction debug output every time udelay
executes.
Change-Id: I5c9b32509562487e53b2acfa1a3f6226d33d1cfd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23748
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
This method lets system call implementations return values into
ThreadContexts other than the one they were called from. That's useful
for, for instance, clone() which creates new ThreadContexts.
By making it a virtual function in the SyscallDesc, we can delegate the
actual implementation to the SyscallDescABI subclass which knows the
ABI and how to use it to set the return value.
Change-Id: I61c6e60e4c2a8863c885cd818e4ff053fc3312ee
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23503
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
