Ok so after a bit of digging, I've figured out the issue. The kernel has different prototypes for __switch_to() for arch/arm and arch/arm64.
In arm64, __switch_to() takes a pointer to the previous task_struct and the next task_struct [1]. In arm32, __switch_to() takes a task_struct pointer and two thread_info pointers [2]. The current implementation of thread_info functions in gem5 all assume that a thread_info address is passed in and thus always tries to extract the task_struct pointer before doing the copies of the fields. However, for arm64, we already have the task_struct and just need to copy from them directly. The only case where we don't have a task_struct in arm64 is where we don't pass in any pointer to curTaskInfo() and have to find it from the thread register [3]. I've created a proof of concept patch that fixes the context switch dumps for aarch64 but breaks them for aarch32 [4]. I wanted to get some input on how best to incorporate this patch upstream so that both aarch32 and aarch64 work. One idea is to add some helper functions that take in pointers to task_struct and do the CopyOut operations on the raw address. The functions that currently expect thread_info structs would first do the lookup to get the task_struct and then call these new helpers. Then, a new DumpPCEventAarch64 would be created that would use the task_struct-based getters from thread_info (basically same as [5]). Does this sound like a reasonable approach? Regards, Paul [1] https://github.com/gem5/linux-arm-gem5/blob/gem5/v4.3/arch/arm64/kernel/process.c#L311 [2] https://github.com/gem5/linux-arm-gem5/blob/gem5/v4.3/arch/arm/kernel/entry-v7m.S#L96 [3] https://github.com/KarateSnowMachine/gem5/pull/1/files#diff-5dd12731563ebe09b1ee1e033b917ba3R114 [4] https://github.com/KarateSnowMachine/gem5/pull/1/files [5] https://github.com/KarateSnowMachine/gem5/pull/1/files#diff-10f6b5e8e711c68fd5034bf3fab6a803R286 -----Original Message----- From: Paul Rosenfeld (prosenfeld) Sent: Wednesday, March 08, 2017 9:35 AM To: gem5 users mailing list <gem5-users@gem5.org> Subject: --enable-context-switch-stats-dump crashes with aarch64 Hello all, I was hoping to enable the context switch stats dumps on an aarch64 simulation but I'm hitting an assertion failure and was wondering if anyone had any ideas before I try to dig into this. The failure is here: #2 0x00000000015d89fa in ArmISA::vtophys (tc=0x81378e0, addr=25769804584) at build/ARM/arch/arm/vtophys.cc:104 104 panic("Table walkers support functional accesses. We should never get here\n"); (gdb) l 99 const std::pair<bool, Addr> translation(try_translate(tc, addr)); 100 101 if (translation.first) 102 return translation.second; 103 else 104 panic("Table walkers support functional accesses. We should never get here\n"); 105 } What I'm doing is checkpointing the aarch64 Ubuntu headless image at the shell right before my program runs and restoring with --enable-context-switch-stats-dump. I've done the same procedure in an aarch32 simulation and it works great. In case it is helpful, here is the relevant portion of the backtrace: #2 0x00000000015d89fa in ArmISA::vtophys (tc=0x81378e0, addr=25769804584) at build/ARM/arch/arm/vtophys.cc:104 #3 0x00000000010b76f7 in FSTranslatingPortProxy::readBlob (this=0x830be40, addr=25769804584, p=0x7fffffff9cd8 "", size=4) at build/ARM/mem/fs_translating_port_proxy.cc:83 #4 0x00000000010b7963 in CopyOut (tc=0x81378e0, dest=0x7fffffff9cd8, src=25769804584, cplen=4) at build/ARM/mem/fs_translating_port_proxy.cc:129 #5 0x0000000001564e67 in Linux::ThreadInfo::curTaskPID (this=0x7fffffff9d20, thread_info=18446743799249746636) at build/ARM/arch/generic/linux/threadinfo.hh:119 #6 0x00000000015642c6 in DumpStatsPCEvent::process (this=0x5f6f320, tc=0x81378e0) at build/ARM/arch/arm/linux/system.cc:291 #7 0x0000000001384e4e in PCEventQueue::doService (this=0x5cc0920, tc=0x81378e0) at build/ARM/cpu/pc_event.cc:107 #8 0x00000000013a8046 in PCEventQueue::service (this=0x5cc0920, tc=0x81378e0) at build/ARM/cpu/pc_event.hh:108 #9 0x00000000013ae4cb in DefaultCommit<O3CPUImpl>::commitInsts (this=0x813c6d8) at build/ARM/cpu/o3/commit_impl.hh:1099 #10 0x00000000013ac4ce in DefaultCommit<O3CPUImpl>::commit (this=0x813c6d8) at build/ARM/cpu/o3/commit_impl.hh:928 #11 0x00000000013ab535 in DefaultCommit<O3CPUImpl>::tick (this=0x813c6d8) at build/ARM/cpu/o3/commit_impl.hh:690 #12 0x00000000013bbf9a in FullO3CPU<O3CPUImpl>::tick (this=0x813a000) at build/ARM/cpu/o3/cpu.cc:560 #13 0x00000000013bfd7c in FullO3CPU<O3CPUImpl>::TickEvent::process (this=0x813a218) at build/ARM/cpu/o3/cpu.cc:148 I'm going to dig into this, but any hints are highly appreciated. Thanks, Paul _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
