summaryrefslogtreecommitdiff
path: root/src/cpu/checker
AgeCommit message (Collapse)Author
2019-12-11cpu: Fix coding style (byteEnable->byte_enable)Giacomo Travaglini
Change-Id: I2206559c6c2a6e6a0452e9c7d9964792afa9f358 Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23282 Maintainer: Jason Lowe-Power <jason@lowepower.com> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
2019-12-11cpu: Add byteEnable assertions to readMem and initateMemReadGiacomo Travaglini
Those are already present in writeMem; looking for consistency Change-Id: Ib85e0db228bc73e3ac64155d1290444cf6864a8c Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23281 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br> Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu> Tested-by: kokoro <noreply+kokoro@google.com> Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
2019-12-10arch,cpu,sim: Push syscall number determination up to processes.Gabe Black
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>
2019-11-07cpu: Fix a bug in getCurrentInstCount in the checker CPU.Gabe Black
An earlier change accidentally left out the actualTC-> prefix in the getCurrentInstCount method which was supposed to delegate the call to another thread context. Without that, it just called itself and would infinitely recurse. This bug was pointed out in email by Robert Henry. Change-Id: Ibf1fee6b48ff87790309c6d435bd76fa95c6cab9 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22623 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-11-02arch,cpu: Move endianness conversion of inst bytes into the ISA.Gabe Black
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>
2019-10-25cpu: Get rid of the nextInstEventCount method.Gabe Black
This was only used by the KVM CPU, and it has access to all it needs to figure out that value locally without requiring all the ThreadContexts to implement an equivalent function. Change-Id: I17a14ce669db2519edf129db761ebd8dc3bd4129 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22114 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-25cpu: Get rid of the serviceInstCountEvents method.Gabe Black
This was useful when transitioning away from the CPU based comInstEventQueue, but now that objects backing the ThreadContexts have access to the underlying comInstEventQueue and can manipulate it directly, they don't need to do so through a generic interface. Getting rid of this function narrows and simplifies the interface. Change-Id: I202d466d266551675ef6792d38c658d8a8f1cb8b Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22113 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-25cpu: Switch off of the CPU's comInstEventQueue.Gabe Black
This switches to letting the ThreadContexts use a thread based/local comInstEventQueue instead of falling back to the CPU's array. Because the implementation is no longer shared and it's not given where the comInstEventQueue (or other implementation) should be accessed, the default implementation has been removed. Also, because nobody is using the CPU's array of event queues, those have been removed. Change-Id: I515e6e00a2174067a928c33ef832bc5c840bdf7f Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22110 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-25cpu,sim: Delegate PCEvent scheduling from Systems to ThreadContexts.Gabe Black
The System keeps track of what events are live so new ThreadContexts can have the same set of events as the other ThreadContexts. Change-Id: Id22bfa0af7592a43d97be1564ca067b08ac1de7c Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22106 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-25cpu: Make the ThreadContext a PCEventScope.Gabe Black
Both the thread and system's PCEventQueue are checked when appropriate. Change-Id: I16c371339c91a37b5641860d974e546a30e23e13 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22105 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-25cpu: Pass the address to check into the PCEventQueue service method.Gabe Black
This prevents having to access it from within the ThreadContext. Change-Id: I34f5815a11201b8fc41871c18bdbbcd0f40305cf Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22102 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-09-23cpu, mem: Changing AtomicOpFunctor* for unique_ptr<AtomicOpFunctor>Jordi Vaquero
This change is based on modify the way we move the AtomicOpFunctor* through gem5 in order to mantain proper ownership of the object and ensuring its destruction when it is no longer used. Doing that we fix at the same time a memory leak in Request.hh where we were assigning a new AtomicOpFunctor* without destroying the previous one. This change creates a new type AtomicOpFunctor_ptr as a std::unique_ptr<AtomicOpFunctor> and move its ownership as needed. Except for its only usage when AtomicOpFunc() is called. Change-Id: Ic516f9d8217cb1ae1f0a19500e5da0336da9fd4f Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20919 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-08-28cpu: Make get(Data|Inst)Port return a Port and not a MasterPort.Gabe Black
No caller uses any of the MasterPort specific properties of these function's return values, so we can instead return a reference to the base Port class. This makes it possible for the data and inst ports to be of any port type, not just gem5 style MasterPorts. This makes life simpler for, for example, systemc based CPUs which might have TLM ports. It also makes it possible for any two CPUs which have compatible ports to be switched between, as long as the ports they use support being unbound. Unfortunately that does not include TLM or systemc ports which are bound permanently. Change-Id: I98fce5a16d2ef1af051238e929dd96d57a4ac838 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20240 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Gabe Black <gabeblack@google.com>
2019-05-30arch, base, cpu, gpu, sim: Merge getMemProxy and getVirtProxy.Gabe Black
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>
2019-05-30cpu, sim: Return PortProxy &s from all the proxy accessors.Gabe Black
This is a step towards merging the accessors for SE and FS modes. Change-Id: I76818ab88b97097ac363e243be9cc1911b283090 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18579 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>
2019-05-11cpu,mem: Add support for partial loads/stores and wide mem. accessesGiacomo Gabrielli
This changeset adds support for partial (or masked) loads/stores, i.e. loads/stores that can disable accesses to individual bytes within the target address range. In addition, this changeset extends the code to crack memory accesses across most CPU models (TimingSimpleCPU still TBD), so that arbitrarily wide memory accesses are supported. These changes are required for supporting ISAs with wide vectors. Additional authors: - Gabor Dozsa <gabor.dozsa@arm.com> - Tiago Muck <tiago.muck@arm.com> Change-Id: Ibad33541c258ad72925c0b1d5abc3e5e8bf92d92 Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/13518 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
2019-05-11cpu: Add a memory access predicateGiacomo Gabrielli
This changeset introduces a new predicate to guard memory accesses. The most immediate use for this is to allow proper handling of predicated-false vector contiguous loads and predicated-false micro-ops of vector gather loads (added in separate changesets). Change-Id: Ice6894fe150faec2f2f7ab796a00c99ac843810a Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17991 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Bradley Wang <radwang@ucdavis.edu> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
2019-04-30cpu: alpha: Delete all occurrances of the simPalCheck function.Gabe Black
This is now handled within the ISA description. Change-Id: Ie409bb46d102e59d4eb41408d9196fe235626d32 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18434 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-04-30cpu: Remove hwrei from the generic interfaces.Gabe Black
This mechanism is specific to Alpha and doesn't belong sprinkled around the CPU's generic mechanisms. Change-Id: I87904d1a08df2b03eb770205e2c4b94db25201a1 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18432 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-04-30arch: cpu: Track kernel stats using the base ISA agnostic type.Gabe Black
Then cast to the ISA specific type when necessary. This removes (mostly) an ISA specific aspect to some of the interfaces. The ISA specific version of the kernel stats still needs to be constructed and stored in a few places which means that kernel_stats.hh still needs to be a switching arch header, for instance. In the future, I'd like to make the kernel its own object like the Process objects in SE mode, and then it would be able to instantiate and maintain its own stats. Change-Id: I8309d49019124f6bea1482aaea5b5b34e8c97433 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18429 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2019-04-29cpu: Get rid of the (read|set)RegOtherThread methods.Gabe Black
These are implemented by MIPS internally now. Change-Id: If7465e1666e51e1314968efb56a5a814e62ee2d1 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18436 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Jason Lowe-Power <jason@lowepower.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-04-22cpu: Eliminate the ProxyThreadContext class.Gabe Black
Replace it with direct inheritance from the ThreadContext class in the SimpleThread class which was the only place it was used. Also take the opportunity to use some specialized types instead of ints, etc., add some consts, and fix some style issues. Change-Id: I5d2cfa87b20dc43615e33e6755c9d016564e9c0e Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18048 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-02-19cpu: Add ISA* getter in Thread interfaceGiacomo Gabrielli
This patch is adding a ISA* getter to the TC interface Change-Id: Ib8ddc5d8fdd44e782f50a2ad15878a6bcf931e58 Reviewed-on: https://gem5-review.googlesource.com/c/16462 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com> Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
2019-02-08cpu: support atomic memory request type with AtomicOpFunctorTuan Ta
This patch enables all 4 CPU models (AtomicSimpleCPU, TimingSimpleCPU, MinorCPU and DerivO3CPU) to issue atomic memory (AMO) requests to memory system. Atomic memory instruction is treated as a special store instruction in all CPU models. In simple CPUs, an AMO request with an associated AtomicOpFunctor is simply sent to L1 dcache. In MinorCPU, an AMO request bypasses store buffer and waits for any conflicting store request(s) currently in the store buffer to retire before the AMO request is sent to the cache. AMO requests are not buffered in the store buffer, so their effects appear immediately in the cache. In DerivO3CPU, an AMO request is inserted in the store buffer so that it is delivered to the cache only after all previous stores are issued to the cache. Data forwarding between between an outstanding AMO in the store buffer and a subsequent load is not allowed since the AMO request does not hold valid data until it's executed in the cache. This implementation assumes that a target ISA implementation must insert enough memory fences as micro-ops around an atomic instruction to enforce a correct order of memory instructions with respect to its memory consistency model. Without extra memory fences, this implementation can allow AMOs and other memory instructions that do not conflict (i.e., not target the same address) to reorder. This implementation also assumes that atomic instructions execute within a cache line boundary since the cache for now is not able to execute an operation on two different cache lines in one single step. Therefore, ISAs like x86 that require multi-cache-line atomic instructions need to either use a pair of locking load and unlocking store or change the cache implementation to guarantee the atomicity of an atomic instruction. Change-Id: Ib8a7c81868ac05b98d73afc7d16eb88486f8cf9a Reviewed-on: https://gem5-review.googlesource.com/c/8188 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Jason Lowe-Power <jason@lowepower.com>
2019-02-05misc: added missing override specifierAndrea Mondelli
Added missing specifier for various virtual functions. Change-Id: I4783e92d78789a9ae182fad79aadceafb00b2458 Reviewed-on: https://gem5-review.googlesource.com/c/16103 Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.com>
2019-02-01cpu, arch: Replace the CCReg type with RegVal.Gabe Black
Most architectures weren't using the CCReg type, and in x86 and arm it was already a uint64_t. Change-Id: I0b3d5e690e6b31db6f2627f449c89bde0f6750a6 Reviewed-on: https://gem5-review.googlesource.com/c/14515 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com>
2019-01-31arch: cpu: Rename *FloatRegBits* to *FloatReg*.Gabe Black
Now that there's no plain FloatReg, there's no reason to distinguish FloatRegBits with a special suffix since it's the only way to read or write FP registers. Change-Id: I3a60168c1d4302aed55223ea8e37b421f21efded Reviewed-on: https://gem5-review.googlesource.com/c/14460 Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Gabe Black <gabeblack@google.com>
2019-01-30arch,cpu: Add vector predicate registersGiacomo Gabrielli
Latest-gen. vector/SIMD extensions, including the Arm Scalable Vector Extension (SVE), introduce the notion of a predicate register file. This changeset adds this feature across architectures and CPU models. Change-Id: Iebcadbad89c0a582ff8b1b70de353305db603946 Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/13715 Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2019-01-22arch: cpu: Stop passing around misc registers by reference.Gabe Black
These values are all basic integers (specifically uint64_t now), and so passing them by const & is actually less efficient since there's a extra level of indirection and an extra value, and the same sized value (a 64 bit pointer vs. a 64 bit int) is being passed around. Change-Id: Ie9956b8dc4c225068ab1afaba233ec2b42b76da3 Reviewed-on: https://gem5-review.googlesource.com/c/13626 Maintainer: Gabe Black <gabeblack@google.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2019-01-16cpu: dev: sim: gpu-compute: Banish some ISA specific register types.Gabe Black
These types are IntReg, FloatReg, FloatRegBits, and MiscReg. There are some remaining types, specifically the vector registers and the CCReg. I'm less familiar with these new types of registers, and so will look at getting rid of them at some later time. Change-Id: Ide8f76b15c531286f61427330053b44074b8ac9b Reviewed-on: https://gem5-review.googlesource.com/c/13624 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com>
2018-12-20arch, cpu: Remove float type accessors.Gabe Black
Use the binary accessors instead. Change-Id: Iff1877e92c79df02b3d13635391a8c2f025776a2 Reviewed-on: https://gem5-review.googlesource.com/c/14457 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Gabe Black <gabeblack@google.com>
2018-11-28cpu,arch-arm: Initialise data membersRekai Gonzalez-Alberquilla
The value that is not initialized has a bogus value that manifests when using some debug-flags what makes the usage of tracediff a bit more challenging. In addition, while debugging with other techniques, it introduces the problem of understanding if the value of a field is 'intended' or just an effect of the lack of initialisation. Change-Id: Ied88caa77479c6f1d5166d80d1a1a057503cb106 Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/13125 Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2018-11-16cpu: Fix the usage of const DynInstPtrRekai Gonzalez-Alberquilla
Summary: Usage of const DynInstPtr& when possible and introduction of move operators to RefCountingPtr. In many places, scoped references to dynamic instructions do a copy of the DynInstPtr when a reference would do. This is detrimental to performance. On top of that, in case there is a need for reference tracking for debugging, the redundant copies make the process much more painful than it already is. Also, from the theoretical point of view, a function/method that defines a convenience name to access an instruction should not be considered an owner of the data, i.e., doing a copy and not a reference is not justified. On a related topic, C++11 introduces move semantics, and those are useful when, for example, there is a class modelling a HW structure that contains a list, and has a getHeadOfList function, to prevent doing a copy to an internal variable -> update pointer, remove from the list -> update pointer, return value making a copy to the assined variable -> update pointer, destroy the returned value -> update pointer. Change-Id: I3bb46c20ef23b6873b469fd22befb251ac44d2f6 Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/13105 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Jason Lowe-Power <jason@lowepower.com>
2018-06-11misc: Using smart pointers for memory RequestsGiacomo Travaglini
This patch is changing the underlying type for RequestPtr from Request* to shared_ptr<Request>. Having memory requests being managed by smart pointers will simplify the code; it will also prevent memory leakage and dangling pointers. Change-Id: I7749af38a11ac8eb4d53d8df1252951e0890fde3 Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/10996 Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
2018-06-11misc: Substitute pointer to Request with aliased RequestPtrGiacomo Travaglini
Every usage of Request* in the code has been replaced with the RequestPtr alias. This is a preparing patch for when RequestPtr will be the typdefed to a smart pointer to Request rather then a raw pointer to Request. Change-Id: I73cbaf2d96ea9313a590cdc731a25662950cd51a Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-on: https://gem5-review.googlesource.com/10995 Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com> Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br> Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
2018-04-27sim,cpu,mem,arch: Introduced MasterInfo data structureGiacomo Travaglini
With this patch a gem5 System will store more info about its Masters. While it was previously keeping track of the Master name and Master ID only, it is now adding a per-Master pointer to the SimObject related to the Master. This will make it possible for a client to query a System for a Master using either the master's name or the master's pointer. Change-Id: I8b97d328a65cd06f329e2cdd3679451c17d2b8f6 Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/9781 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
2018-01-09cpu, power: Get rid of the remnants of the EA computation insts.Gabe Black
Get rid of some remnants of a system which was intended to separate address computation into its own instruction object. Change-Id: I23f9ffd70fcb89a8ea5bbb934507fb00da9a0b7f Reviewed-on: https://gem5-review.googlesource.com/7122 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Gabe Black <gabeblack@google.com>
2017-12-22arch,cpu: "virtualize" the TLB interface.Gabe Black
CPUs have historically instantiated the architecture specific version of the TLBs to avoid a virtual function call, making them a little bit more dependent on what the current ISA is. Some simple performance measurement, the x86 twolf regression on the atomic CPU, shows that there isn't actually any performance benefit, and if anything the simulator goes slightly faster (although still within margin of error) when the TLB functions are virtual. This change switches everything outside of the architectures themselves to use the generic BaseTLB type, and then inside the ISA for them to cast that to their architecture specific type to call into architecture specific interfaces. The ARM TLB needed the most adjustment since it was using non-standard translation function signatures. Specifically, they all took an extra "type" parameter which defaulted to normal, and translateTiming returned a Fault. translateTiming actually doesn't need to return a Fault because everywhere that consumed it just stored it into a structure which it then deleted(?), and the fault is stored in the Translation object when the translation is done. A little more work is needed to fully obviate the arch/tlb.hh header, so the TheISA::TLB type is still visible outside of the ISAs. Specifically, the TlbEntry type is used in the generic PageTable which lives in src/mem. Change-Id: I51b68ee74411f9af778317eff222f9349d2ed575 Reviewed-on: https://gem5-review.googlesource.com/6921 Maintainer: Gabe Black <gabeblack@google.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2017-12-05cpu: Add support for CMOs in the cpu modelsNikos Nikoleris
Cache maintenance operations go through the write channel of the cpu. This changes makes sure that the cpu does not try to fill in the packet with data. Change-Id: Ic83205bb1cda7967636d88f15adcb475eb38d158 Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5055 Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2017-07-05cpu: Added interface for vector reg fileRekai Gonzalez-Alberquilla
This patch adds some more functionality to the cpu model and the arch to interface with the vector register file. This change consists mainly of augmenting ThreadContexts and ExecContexts with calls to get/set full vectors, underlying microarchitectural elements or lanes. Those are meant to interface with the vector register file. All classes that implement this interface also get an appropriate implementation. This requires implementing the vector register file for the different models using the VecRegContainer class. This change set also updates the Result abstraction to contemplate the possibility of having a vector as result. The changes also affect how the remote_gdb connection works. There are some (nasty) side effects, such as the need to define dummy numPhysVecRegs parameter values for architectures that do not implement vector extensions. Nathanael Premillieu's work with an increasing number of fixes and improvements of mine. Change-Id: Iee65f4e8b03abfe1e94e6940a51b68d0977fd5bb Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> [ Fix RISCV build issues and CC reg free list initialisation ] Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/2705
2017-07-05cpu: Result refactoringRekai Gonzalez-Alberquilla
The Result union used to collect the result of an instruction is now a class of its own, with its constructor, and explicit casting methods for cleanliness. This is also a stepping stone to have vector registers, and instructions that produce a vector register as output. Change-Id: I6f40c11cb5e835d8b11f7804a4e967aff18025b9 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/2703 Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2017-07-05cpu: Simplify the rename interface and use RegIdRekai Gonzalez-Alberquilla
With the hierarchical RegId there are a lot of functions that are redundant now. The idea behind the simplification is that instead of having the regId, telling which kind of register read/write/rename/lookup/etc. and then the function panic_if'ing if the regId is not of the appropriate type, we provide an interface that decides what kind of register to read depending on the register type of the given regId. Change-Id: I7d52e9e21fc01205ae365d86921a4ceb67a57178 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> [ Fix RISCV build issues ] Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/2702
2017-07-05arch, cpu: Architectural Register structural indexingNathanael Premillieu
Replace the unified register mapping with a structure associating a class and an index. It is now much easier to know which class of register the index is referring to. Also, when adding a new class there is no need to modify existing ones. Change-Id: I55b3ac80763702aa2cd3ed2cbff0a75ef7620373 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> [ Fix RISCV build issues ] Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/2700
2017-02-27syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess ↵Brandon Potter
simulations Modifies the clone system call and adds execve system call. Requires allowing processes to steal thread contexts from other processes in the same system object and the ability to detach pieces of process state (such as MemState) to allow dynamic sharing.
2015-07-20syscall_emul: [patch 13/22] add system call retry capabilityBrandon Potter
This changeset adds functionality that allows system calls to retry without affecting thread context state such as the program counter or register values for the associated thread context (when system calls return with a retry fault). This functionality is needed to solve problems with blocking system calls in multi-process or multi-threaded simulations where information is passed between processes/threads. Blocking system calls can cause deadlock because the simulator itself is single threaded. There is only a single thread servicing the event queue which can cause deadlock if the thread hits a blocking system call instruction. To illustrate the problem, consider two processes using the producer/consumer sharing model. The processes can use file descriptors and the read and write calls to pass information to one another. If the consumer calls the blocking read system call before the producer has produced anything, the call will block the event queue (while executing the system call instruction) and deadlock the simulation. The solution implemented in this changeset is to recognize that the system calls will block and then generate a special retry fault. The fault will be sent back up through the function call chain until it is exposed to the cpu model's pipeline where the fault becomes visible. The fault will trigger the cpu model to replay the instruction at a future tick where the call has a chance to succeed without actually going into a blocking state. In subsequent patches, we recognize that a syscall will block by calling a non-blocking poll (from inside the system call implementation) and checking for events. When events show up during the poll, it signifies that the call would not have blocked and the syscall is allowed to proceed (calling an underlying host system call if necessary). If no events are returned from the poll, we generate the fault and try the instruction for the thread context at a distant tick. Note that retrying every tick is not efficient. As an aside, the simulator has some multi-threading support for the event queue, but it is not used by default and needs work. Even if the event queue was completely multi-threaded, meaning that there is a hardware thread on the host servicing a single simulator thread contexts with a 1:1 mapping between them, it's still possible to run into deadlock due to the event queue barriers on quantum boundaries. The solution of replaying at a later tick is the simplest solution and solves the problem generally.
2016-11-09style: [patch 1/22] use /r/3648/ to reorganize includesBrandon Potter
2016-08-15cpu, arch: fix the type used for the request flagsNikos Nikoleris
Change-Id: I183b9942929c873c3272ce6d1abd4ebc472c7132 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
2016-04-07mem: Remove threadId from memory request classMitch Hayenga
In general, the ThreadID parameter is unnecessary in the memory system as the ContextID is what is used for the purposes of locks/wakeups. Since we allocate sequential ContextIDs for each thread on MT-enabled CPUs, ThreadID is unnecessary as the CPUs can identify the requesting thread through sideband info (SenderState / LSQ entries) or ContextID offset from the base ContextID for a cpu. This is a re-spin of 20264eb after the revert (bd1c6789) and includes some fixes of that commit.
2016-04-06Revert power patch sets with unexpected interactionsAndreas Sandberg
The following patches had unexpected interactions with the current upstream code and have been reverted for now: e07fd01651f3: power: Add support for power models 831c7f2f9e39: power: Low-power idle power state for idle CPUs 4f749e00b667: power: Add power states to ClockedObject Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> --HG-- extra : amend_source : 0b6fb073c6bbc24be533ec431eb51fbf1b269508
2016-04-05mem: Remove threadId from memory request classMitch Hayenga
In general, the ThreadID parameter is unnecessary in the memory system as the ContextID is what is used for the purposes of locks/wakeups. Since we allocate sequential ContextIDs for each thread on MT-enabled CPUs, ThreadID is unnecessary as the CPUs can identify the requesting thread through sideband info (SenderState / LSQ entries) or ContextID offset from the base ContextID for a cpu.