Hi Giacomo, KVM indeed worked in x86, but my target application would eventually hang with O3CPU because gem5-X86 does not guarantee the atomicity of synchronization variables in multithreaded programs with the classic memory system (needed by KVM).
So I'm once again considering gem5+ARM, because I know that at least my multi-threaded program would work properly in full-system. Hence, I'd like to try to fix this unimplemented instruction, as you mentioned. Could you provide me some help on how to do that? Let me tell you what I've been trying recently: First I should say that the ARM machine I have is in fact an NVIDIA Jetson AGX Xavier with 8-core ARM v8.2. The OS on the boards is an NVIDIA-specific Linux version (based on ubuntu 18) and I thought that, perhaps, their modifications could be causing KVM to trigger an instruction that is not found in a 'regular' Ubuntu host. So I had prepared a ubuntu docker container to run gem5+kvm on the board, and see if that would make any difference. But not really. I get a similar (yet smaller/cut-out) output from the terminal when I try to restore from a KVM-taken checkpoint into the atomic CPU: ./build/ARM/gem5.opt configs/example/arm/fs_bigLITTLE.py --big-cpus 2 --little-cpus 0 --cpu-type atomic --disk /scratch/pedro/ubuntu-18.04-arm64-8gb.img --kernel /scratch/pedro/aarch-system-20210904/binaries/vmlinux.arm64 --bootscript configs/boot/my_script.rcS --restore-from m5out/cpt.8185197130500 [ 5.841787] Internal error: undefined instruction: 0 [#1] PREEMPT SMP [ 5.841790] Modules linked in: [ 5.841795] CPU: 1 PID: 83 Comm: kworker/1:2 Not tainted 4.18.0+ #1 [ 5.841798] Hardware name: V2P-CA15 (DT) So I proceed to use DFLAGS, as you suggested, to check what was the undefined instruction. For that I added the `--debug-flags=Faults` in the previous command. This returned me the following: . . . system.terminal: Listening for connections on port 3456 system.realview.uart1.device: Listening for connections on port 3457 system.realview.uart2.device: Listening for connections on port 3458 system.realview.uart3.device: Listening for connections on port 3459 0: system.remote_gdb: listening for remote gdb on port 7000 0: system.remote_gdb: listening for remote gdb on port 7001 build/ARM/dev/arm/energy_ctrl.cc:249: warn: Existing EnergyCtrl, but no enabled DVFSHandler found. build/ARM/sim/simulate.cc:104: info: Entering event queue @ 8185197130500. Starting simulation... 8185197140500: IRQ: Invoking Fault (AArch64 target EL):IRQ cpsr:0x404003c5 PC:0xffffff8008179f28 elr:0xffffff8008179f28 newVec: 0xffffff8008081a80 8185197353000: IRQ: Invoking Fault (AArch64 target EL):IRQ cpsr:0x80c003c5 PC:0xffffff800872e848 elr:0xffffff800872e848 newVec: 0xffffff8008081a80 8185210545000: Undefined Instruction: Invoking Fault (AArch64 target EL):Undefined Instruction cpsr:0x604003c5 PC:0xffffff80080863cc elr:0xffffff80080863cc newVec: 0xffffff8008081a00 inst: 0xd500417f 8185229553500: Undefined Instruction: Invoking Fault (AArch64 target EL):Undefined Instruction cpsr:0x604003c5 PC:0xffffff800816fbd4 elr:0xffffff800816fbd4 newVec: 0xffffff8008081a00 inst: 0xd500417f 8185295569000: ArmSev Flush: Invoking ArmSev Fault 8185621086500: ArmSev Flush: Invoking ArmSev Fault 8185946604000: ArmSev Flush: Invoking ArmSev Fault 8186272121000: ArmSev Flush: Invoking ArmSev Fault (I killed gem5 at this point, this "ArmSev Flush" message was being repeated and the terminal output was already there). So I went to look directly at the instruction `inst: 0xd500417f` -> 1101 0101 0000 0000 0100 0001 0111 1111 (which is the same in both lines reporting undefined instruction). After searching in the reference manual for armv8 (https://developer.arm.com/documentation/ddi0487/gb/) I think it is the MSR (immediate) instruction (at C6.2.195 in the manual). And then I found different matches for 'msr' in the file src/arch/arm/isa/formats/aarch64.isa. However, I'm not very familiar with the instruction and possible implications of implementing it.. Do you have any suggestions for me on where to start and if it is indeed doable? Any other relevant information from debug values 'cpsr' 'elr' or 'newVec' that I should be aware of? Once again, thank you very much for any feedback. Pedro. _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
