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>
The definition of ioctl is not actually variadic, it just doesn't
specify what the type of the pointer is that it takes as its third
argument. The man page says that that's because it predates void *
being valid C.
By passing this address around (even if it's unused), we avoid having
to extract system call arguments further down the call stack.
Change-Id: I62541237baafaec30bbe3df06b3284dd286a4051
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23456
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Having readable constants for these large numbers is good, but they
used incorrect style, were at global scope, and were only used in one
place.
This change centralizes them where they're used, fixes their style, and
rewrites the actual constants in a way that makes it clear what they're
values are.
Change-Id: Ib89c46fce133d4180296d384a61d51d1fe1f8d20
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23455
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@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>
These ABIs (one 32 bit and one 64 bit) take advantage of the
GenericSyscallABI and X86Linux::SyscallABI partial ABIs set up earlier.
This removes x86's dependence on the getSyscallArg and setSyscallReturn
Process methods.
Change-Id: Ia07834cea1afa827d77e590af5397e2a1e0e2099
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23443
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It's very common for system call arguments to be passed in a sequence
of registers, one argument per register. To avoid having that
implementation repeated over and over across the various ISAs and OSes,
these partial ABI implementations provide that mechanism they can just
pull in. They would need to define the sequence of registers to use,
and these would take care of the rest.
Unlike the temporary DefaultSyscallABI which defers to the Process
classes, these read registers from the ThreadContext directly.
Change-Id: Ic72eb8d784ecf4711b5eec76d958a87c70850fce
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23441
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When the new thread context ctc is created, it should have a copy of
all the state in the original tc, including the original PC. This code
used to specially handle the KVM case by explicitly making this new
context return from the system call immediately by jumping right to
RCX which (assuming a particular instruction was used) is where user
mode should resume.
The first problem with this approach as far as I can tell is that the
CPU will still be in CPL0, ie supervisor mode, and will not have been
forced back into CPL3, ie user mode. This may not have any immediately
visible effect, but may down the line.
Second, this seems unnecessary. The non-special case code will advance
the PC beyond the instruction which triggered the system call. Then
once the new thread starts executing again, it will execute sysret and
return to rcx naturally, just like the original thread will.
The only observed difference is that when executing a gem5 instruction,
the IP is set to the currently executing instruction, and so to avoid
the new context from re-executing the system call, the PC needs to be
advanced. When calling in from KVM, the instruction has already been
"completed", and so the IP should *not* be advanced.
Also note that when reading the PCState object in KVM, it doesn't
figure out where the next instruction is and so NPC is just one
ExtMachInst sized blob later on. Advancing the PC will just move to
an address 8 bytes later, which is very unlikely to be what you want.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I0d97f66e64ce39b13d6700dcf3d7da88d6fe0048
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23199
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 GenericTimer specification includes a global component for
a universal view of time: the System Counter.
If both per-PE architected and memory-mapped timers are instantiated
in a system, they must both share the same counter. SystemCounter is
promoted to be an independent SimObject, which is now shared by
implementations.
The SystemCounter may be controlled/accessed through the memory-mapped
counter module in the system level implementation. This provides
control (CNTControlBase) and status (CNTReadBase) register frames. The
counter module is now implemented as part of GenericTimerMem.
Frequency changes occur through writes to an active CNTFID or to
CNTCR.EN as per the architecture. Low-high and high-low transitions are
delayed until suitable thresholds, where the counter value is a divisor
of the increment given the new frequency.
Due to changes in frequency, timers need to be notifies to be
rescheduled their counter limit events based on CompareValue/TimerValue.
A new SystemCounterListener interface is provided to achieve
correctness.
CNTFRQ is no longer able to modify the global frequency. PEs may
use this to modify their register view of the former, but they should
not affect the global value. These two should be consistent.
With frequency changes, counter value needs to be stored to track
contributions from different frequency epochs. This is now handled
on epoch change, counter disable and register access.
References to all GenericTimer model components are now provided as
part of the documentation.
VExpress_GEM5_Base is updated with the new model configuration.
Change-Id: I9a991836cacd84a5bc09e5d5275191fcae9ed84b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25306
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
getArmSystem is the building block for a lot of ArmSystem getters
a client can use to check for a specific feature.
This method is called very often during simulation and it is basically
casting a System pointer into an ArmSystem pointer.
To do so, it is using dynamic casting to check if the system is really
an ArmSystem. This is very expensive and usually not needed.
The only chance arm code would use a non ArmSystem is when in SE mode.
But if that's the case, we can just replace the assertion with a
assert(FullSystem).
Testing Linux boot with this patch provides a speedup of nearly 2x!
(atomic mode).
This is partially related to:
JIRA: https://gem5.atlassian.net/browse/GEM5-337
Since the PAuth patch changed the purifyTagged helper (on the critical
path of simulation) to rely more heavilly on getArmSystem (via
ArmSystem:: static methods)
Change-Id: Idbf079548ffe03513b4fc58c76f0d69613952a50
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25964
Tested-by: kokoro <noreply+kokoro@google.com>
Python 2.x and Python 3 use different meta class syntax. Fix this by
implementing meta classes using the add_metaclass decorator in the six
Python library.
Due to the way meta classes are implemented in six,
MetaParamValue.__new__ seems to be called twice for some classes. This
triggers an assertion which when param that checks that Param types
have only been registered once. I have turned this assertion into a
warning.
The assertion was triggered in params.CheckedInt and params.Enum. It
seems like the cause of the issue is that these classes have their own
meta classes (CheckedIntType and MetaEnum) that inherit from
MetaParamValue and a base class (ParamValue) that also inherits from
MetaParamValue.
Change-Id: I5dea08bf0558cfca57897a124cb131c78114e59e
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26083
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
