Hi Pedro, The MSR (immediate) is the software interface for modifying the PSTATE of the PE. In this case the instruction is trying to change the PSTATE.UAO field, which is not implemented in gem5
This is why you are not able to restore the checkpoint in atomic. Implementing UAO should fix it. I can try to allocate some time to do it myself. Other options in the meantime could be to check if there is an UAO option in the kconfig and disable it Kind Regards Giacomo > -----Original Message----- > From: Pedro Becker via gem5-users <gem5-users@gem5.org> > Sent: 30 August 2021 12:47 > To: gem5-users@gem5.org > Cc: Pedro Becker <pe...@ac.upc.edu> > Subject: [gem5-users] Re: Boot FS with kvm and multiple cores > > 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ 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
