spec2017 gem5 x86 MOVNTDQ tried to write to umapped address - gem5

Question

I am running spec2017 on Gem5 (X86 Arch) in SE mode, but I found some benchmarks, like 549.fotonik3d_r, will met this problem:
build/X86/arch/generic/debugfaults.hh:145: warn: MOVNTDQ: Ignoring non-temporal hint, modeling as cacheable!
build/X86/arch/x86/faults.cc:165: panic: Tried to write unmapped address 0x7ffff7fff048.
PC: (0x51d240=>0x51d249).(1=>2), Instr: MOVNTDQ_M_XMM : cda DS:[rdi + 0x2008]
Memory Usage: 16945308 KBytes
Program aborted at tick 661950210922
--- BEGIN LIBC BACKTRACE ---
/home/qishao/Project/gem5/build/X86/gem5.opt(+0x77d320)[0x560f34385320]
/home/qishao/Project/gem5/build/X86/gem5.opt(+0x7a3a23)[0x560f343aba23]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f9deff71520]
/lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0x12c)[0x7f9deffc5a7c]
But I can run it on X86KvmCPU, failed in X86Atomic or X86Timing CPU. I don't know which part goes wrong, the way I compile spec2017 or the way it runs in SE mode.
Thanks for your help.

Answer 1

It is due to this address is beyond stack region thus I expend max stack size in src/arch/x86/process.cc. After that, I met another bug, with address 0x7fff_ffff_ffff_0048, which is larger than current stack base 0x7fff_ffff_ffff_0000. Thus I implement a similar code to make stack grow inversely to avoid this problem, shown in the following. Now, it seems worked and I run in single thread mode, so stack might can work this way. But I wonder how others get pass through this problem.
## -445,6 +450,18 ## MemState::fixupFault(Addr vaddr)
return true;
}
+ if (vaddr > _stackBase) {
+ while (vaddr > _stackBase) {
+ DPRINTF(Vma,"warning: inversely increase stack base %0#x to avoid addr %0#x assert.",
+ vaddr, _stackBase, _stackBase);
+ _stackBase += _pageBytes;
+ _maxStackSize+=_pageBytes;
+ _ownerProcess->allocateMem(_stackBase, _pageBytes);
+ inform("Increasing stack size by one page.");
+ }
+ return true;
+ }
+
return false;