summaryrefslogtreecommitdiff
path: root/src/cpu
AgeCommit message (Collapse)Author
2019-11-26cpu: prefix ExecEnable to the native trace to match DPRINTFCiro Santilli
The trace mechanism appears to be the only debug flag that does not go through DPRINTF, presumably for performance reasons. This patch manually adds that to make things uniform with other debug flags, e.g. with FmtFlag,ExecAll,SyscallBase a sample output looks like (truncated to fit into commit message lengths): 0: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue 500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+4 1000: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+8 1500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+12 2000: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+16 2500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+20 3000: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+24 3500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+28 Change-Id: Ic371ebc8b0827656f1b78fcfd3f28505a5100274 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22007 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-11-26base: generalize ExecTicks to all messages with FmtTicksOffCiro Santilli
If FmtTicksOff is given, ticks are disabled for all log messages. The original motivation of this is to bring the implementation of native traces closer to that of other traces to help refactoring done in future patches. One additional advantage of this is that sometimes we want to compare traces of a given program under different conditions, so the start of the ROI is different, and the different initial timestamp makes a diff useless by showing differences on every line. Change-Id: Idd6cb105d301b3b9b064996043f4ca75ddafe0af Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22006 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-11-26arch,cpu: Get rid of ISA_HAS_CC_REGS and its associated ifdefs.Gabe Black
This conditional compilation was unnecessary and makes gem5 more brittle and harder to understand. Change-Id: I63abaf2668252c988cdd4626ff6a462eb6f54b04 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22544 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-11-25cpu: log thread activate and suspend with --debug-flags ThreadCiro Santilli
The original motivation of this is to help debug syscall emulation deadlocks. Change-Id: I1c4f611fa2f2e464a30dc92baac89ca819e16a97 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21759 Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu> Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu> Tested-by: kokoro <noreply+kokoro@google.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-06cpu: Use std::array for registers in SimpleThread.Gabe Black
If the number of one of the register types is zero (useful on ARM in the near future), memset will complain that it's given the length of the array without multiplying by the size of the array elements. This is a false positive since the length of the array and the number of elements are both zero. To avoid that warning/error and to simplify and update the SimpleThread class slightly, this change replaces the C style arrays with std::array. Change-Id: Ifedd081a1940a578765c4d585e623236008ace67 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22523 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Gabe Black <gabeblack@google.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-31cpu-o3: bugfix for partial faults in x86Brandon Potter
The c58cb8c9 changeset broke some code related to checking consistency model guarantees (found in X86 benchmarks). This changeset adds some documentation to the code and obviates the problem. Change-Id: Ied9c6b0b1d237538efe4beb2f97ef76248ce2746 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22283 Maintainer: Brandon Potter <Brandon.Potter@amd.com> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
2019-10-30cpu-o3: Fix handling of some mem. order violationsGiacomo Gabrielli
This patch fixes the handling of memory order violations due to snoops targeting out-of-order loads: the re-execution triggered in these cases is achieved by raising a ReExec fault, but such a fault was not handled correctly after the code changes introduced in changeset 46da8fb. Change-Id: I2abe161a90468412f56cb28dcc92729326cba1cd Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21819 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Timothy Hayes <timothy.hayes@arm.com> Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.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: Access inst events through ThreadContext instead of the CPU.Gabe Black
Also delete the CPU interface. Change-Id: I62a6b0a9a303d672f4083bdedf393f9f6d07331f Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22109 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: Delegate comInstEventQueue methods to the ThreadContexts.Gabe Black
These then just use the comInstEventQueue array from the CPU, but soon they will actually be self contained and allow the thread context to use whatever mechanism it wants. Also, now that the thread contexts need to exist before instruction count based events can be scheduled, setting up max instruction based events needs to happen in init after the CPU subclasses have had a chance to set up the threadContexts vector. Change-Id: I34bb401633d277a60be74e30d5a478a149b972ea Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22108 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: Make accesses to comInstEventQueue indirect through methods.Gabe Black
This lets us move the event queue itself around, or change how those services are provided. Change-Id: Ie36665b353cf9788968f253cf281a854a6eff4f4 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22107 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Gabe Black <gabeblack@google.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,sim: Get rid of a bunch of conditional compilation for PCEvents.Gabe Black
These can now be built without referring to anything in ThreadContext and so can be built even with the NULL ISA. This means the pcEventQueue can be unconditionally built into the System class. Even though the pcEventQueue is going away, this still makes it possible for System to be a PCEventScope unconditionally. Change-Id: Ia342bb7972b1b5ce95033176d72af4bfa343560f Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22104 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: Don't print the CPU name when a (Break|Panic)PCEvent happens.Gabe Black
This requires reaching into the threadcontext to access the CPU pointer, and also isn't all that useful since it's more important what event happened, not what CPU happened to be running the code at that time. Change-Id: I368707c804dff9bd349f3261bdcd08be55c5d04a Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22103 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-10-25cpu: Stop checking for PC changes when servicing a PCEventQueue.Gabe Black
First of all, this would arbitrarily skip events based on when they were encountered in the queue. Second, this is one of the three places where the ThreadContext is actually accessed in pc_event.cc. By removing this and the other uses, this file can be included even when using the NULL ISA, and a lot of #ifdefs can be removed. Change-Id: If81f5e9ff9d3f9833145fec0b6062b4bda8d2e47 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22100 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: Create a PCEventScope class to abstract the scope of PCEvents.Gabe Black
This abstraction will allow scheduling PCEvents for a particular ThreadContext, all contexts on a CPU, all contexts in a system, etc., and delegates scheduling and removing events to each particular scope. Right now the PCEventQueue is the only implementor of the PCEventSCope interface. Change-Id: I8fb62931511136229915c2e19d36aae7ffdec9df Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22099 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-23cpu: Apply the ARM TLB rework to the O3 checker CPU.Gabe Black
The TLBs now create the stage 2 MMUs as children, and since those are specialized for instruction and data, the CPU needs to use ArmITB or ArmDTB instead of ArmTLB which is the base class without an MMU. This was changed for the BaseCPU and SimpleCPU checker already, but the TLBs are added in the O3 checker CPU as well. Change-Id: I498f247f376c8721fb70ce26c0f1b0815b12fe2d Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22039 Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-21cpu: Apply the ARM TLB rework to the checker CPU.Gabe Black
The TLBs now create the stage 2 MMUs as children, and since those are specialized for instruction and data, the CPU needs to use ArmITB or ArmDTB instead of ArmTLB which is the base class without an MMU. This was changed for the BaseCPU already, but the TLBs are added in the checker CPU as well. Change-Id: Ide8ce950622b40f69c37bbe2ea0d22295b76d7a6 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21979 Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-19cpu,arm: Push the stage 2 MMUs out of the CPU into the TLBs.Gabe Black
This regularizes the TLB setup in the CPU so that ARM is no longer a special case with extra objects. Change-Id: I739b82578ff74f8f9777cd7e34cd5227b47b186c Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21842 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>
2019-10-19arch: Make a base class for Interrupts.Gabe Black
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>
2019-10-18cpu: Turn the stage 2 ARM MMUs from params to children.Gabe Black
These aren't referred to in the C++, so there's no reason for them to be parameters. By making them children, they can still be modified, replaced wholesale, or even replaced by an entirely different object to, for instance, mask them when they're not needed. Change-Id: Ic7f144a3cd3d1fca12fec220918aa72af885f61c Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21839 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-17cpu: Clean up some style issues in pc_event.(hh|cc).Gabe Black
The record_t typedef isn't all that helpful, and is also not consistent with gem5 style. The map_t style is more useful but is also not compliant. This change eliminates the first typedef and replaces the second with a type called Map. There are some other small style fixups added in as well, like making the member variable pc_map pcMap. Change-Id: I8ffea529004fd6d5b42fdc60250804e2e4987e88 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21781 Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-17cpu: Get rid of load count based events.Gabe Black
This was initially added in 2003 and only supported in the simple CPUs. It's oddly specific since there are no other similar event queues for, for instance, stores, branches, system calls, etc. Given that this seems like a historical oddity which is only partially supported and would be very hard to support on more diverse CPU types like KVM or fast model which don't generally have hooks for counts of specific instruction types. Change-Id: I29209b7ffcf896cf424b71545c9c7546f439e2b9 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21780 Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-15cpu: Delete the unused sched_break_pc(_sys) functions.Gabe Black
Change-Id: I2adae2858897e665fd28cfe9de3fdcf95ffc2a2e Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21779 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-15sim,cpu: Get rid of the unused instEventQueue.Gabe Black
This queue was set up to allow triggering events based on the total number of instructions executed at the system level, and was added in a change which added a number of things to support McPAT. No code checked into gem5 actually schedules an event on that queue, and no code in McPAT (which seems to have gone dormant) either downloadable from github or found in ext modify gem5 in a way that makes it use the instEventQueue. Also, the KVM CPU does not interact with the instEventQueue correctly. While it does check the per-thread instruction event queue when deciding how long to run, it does not check the instEventQueue. It will poke it to run events when it stops for other reasons, but it may (and likely will) have run beyond the point where it was supposed to stop. Since this queue doesn't seem to actually be used for anything, isn't being used properly in all cases anyway, and adds overhead to all the CPU models, this change eliminates it. Change-Id: I0e126df14788c37a6d58ca9e1bb2686b70e60d88 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21783 Maintainer: Gabe Black <gabeblack@google.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Tiago Mück <tiago.muck@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-10-04kvm: Rename gettid() to build with glibc 2.30+Tommaso Marinelli
glibc 2.30 introduced the function gettid() in sys/types.h to return the caller's thread ID. In order to avoid conflicts, the already present gettid() functions have been renamed to sysGettid(). This fixes a compilation error with X86 arch. Change-Id: I76c971465fc4b50e4decde8303185439082b2378 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21379 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu> Maintainer: Jason Lowe-Power <jason@lowepower.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-09-30cpu: Make use of DRAMCtrl::AddrMap in the traffic generatorsNikos Nikoleris
Use the enum defined in the memory controller rather than custom strings and int that are later converted to the DRAMCtrl::AddrMap enum. Change-Id: Ie5b19f915f9990fd2b7505d4d1b17b6fc2100f9e Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21080 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-09-24cpu: Fix checker cpu instantiationNikos Nikoleris
This change uses the params as instantiated from the default constructor to create the checker cpu. If any of these parameters are invalid for the checker cpu, the simulation will exit with a warning. Change-Id: I0e58ed096c9ea5f413f2e9b64d8d184d9b0fc84e Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21079 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.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-09-04cpu: reset byte_enable across writeMem callsCiro Santilli
data_write_req byteEnable which is used in ARM SVE partial writes was not being zeroed between writes. As a result, non-SVE memory write instructions such as STP that followed SVE memory write instructions could still have the write mask active. This could lead to wrong simulation behaviour, and to an assertion failure: src/mem/packet.hh:1211: void Packet::writeData(uint8_t*) const: Assertion `req->getByteEnable().size() == getSize()' failed. '` Change-Id: I74b5a82675e9923b0ffdf2c1dd9afb00c91cb204 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20448 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-08-29cpu: Convert traffic gen to use new statsAndreas Sandberg
Change-Id: Ife690a137c2dcfb6bcc8b22df996c84f0d231618 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19370 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.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-08-28cpu, mem: Add new getSendFunctional method to the base CPU.Gabe Black
This returns a sendFunctional delegate references which can be used to send functional accesses directly, or more likely when constructing a PortProxy subclass. In those cases only the functional capabilities of those ports are needed so there's no reason to require a full port which supports all three protocols. Also, this removes the last remaining use of get(Data|Inst)Port which relies on those returning a port which supports the gem5 protocols, except the default implementations of this new function. If a CPU doesn't have traditional gem5 style ports, it can override this function to do whatever other behavior is necessary and return its real ports through get(Data|Inst)Port. Change-Id: Ide4da81e3bc679662cd85902ba6bd537cce54a53 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20237 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Gabe Black <gabeblack@google.com>
2019-08-28cpu: Move the instruction port into o3's fetch stage.Gabe Black
That's where it's used, and that avoids having to pass it around using the top level getInstPort accessor. Change-Id: I489a3f3239b3116292f3dcd78a3945fb468c6311 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20239 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Gabe Black <gabeblack@google.com>
2019-08-28cpu: Move O3's data port into the LSQ.Gabe Black
That's where it's used, and putting it there avoids having to pass around the port using the top level getDataPort function. Change-Id: I0dea25d0c5f4bb3f58a6574a8f2b2d242784caf2 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20238 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Gabe Black <gabeblack@google.com>
2019-08-27cpu, dev, mem: Use the new Port methods.Gabe Black
Use getPeer, takeOverFrom, and << to simplify the use of ports in some areas. Change-Id: Idfbda27411b5d6b742f5e4927894302ea6d6a53d Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20235 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2019-08-23mem: Move ruby protocols into a directory called ruby_protocol.Gabe Black
Now that the gem5 protocols are split out, it would be nice to put them in their own protocol directory. It's also confusing to have files called *_protocol which are not in the protocol directory. Change-Id: I7475ee111630050a2421816dfd290921baab9f71 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20230 Reviewed-by: Gabe Black <gabeblack@google.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-08-21arch-arm, cpu: fix ARM ubsan build on GCC 7.4.0Ciro Santilli
In src/cpu/reg_class.hh, numPinnedWrites was unset because the constructors were not well factored out. Change-Id: Ib2fc8d34a1adf5c48826d257a31dd24dfa64a08a Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20048 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-08-10cpu: Pull more arch specialization to the top of BaseCPU.py.Gabe Black
This simplifies the logic of the CPU python class, and brings us ever so slightly closer to factoring hardcoded ISA behavior out of non-ISA specific components. Change-Id: I7e4511dd4e6076f5c214be5af2a0e33af0142563 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19889 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2019-08-10x86: Move some fixed or dummy config information into X86LocalApic.py.Gabe Black
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>
2019-08-07cpu-o3: fix atomic instructions non-speculativeJordi Vaquero
Fix problem with O3 and AMO instructions. At initial stages amo instruction is considered a type of non-speculative store. After the instruction has been commited and during the squash step, acquire_release version of the AMO operation is considered speculative, that differents results in an assert fault. This fix ensures that AMO instructions are always considered non-speculative, during early stages and during squas/removal of the instruction. Change-Id: Ia0c5fbb9dc44a9991337b57eb759b1ed08e4149e Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19815 Maintainer: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Tested-by: kokoro <noreply+kokoro@google.com>
2019-08-07cpu-o3: added _amo_op parameter in o3 LSQJordi Vaquero
Fix bug with AMO (or RMW) instructions where the amo_op variable is not being propagated to the LSQ request. Change-Id: I60c59641d9b497051376f638e27f3c4cc361f615 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19814 Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
2019-07-28cpu: Fix the type of the effective mem request sizeGabor Dozsa
A memory request size can be larger than 255 bytes (e.g. SVE with 2048-bit vector length) which could cause overflow in the 'uint8_t effSize' variable. Change-Id: I77e0d02a49ea7f81cacfa5be7e4ae40434af3109 Reviewed-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com> Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19175 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-07-28cpu-o3: Fix too strict assert condition in writeback()Gabor Dozsa
The assert() in the LSQ writeback() only allowed ReExec faults. However, a SplitRequest which completed the translation in PartialFault state (i.e. any but the very first cacheline translation failed) may end up here. The assert() condition is extended accordingly. The patch also removes the superfluous/unused Complete/Squashed states from the LSQ request. (The completion of the request is recorded in the flags still.) Change-Id: Ie575f4d3b4d5295585828ad8c7d3f4c7c1fe15d0 Signed-off-by: Gabor Dozsa <gabor.dozsa@arm.com> Reviewed-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19174 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com> Maintainer: Jason Lowe-Power <jason@lowepower.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-03-26 19:37:27 +0000