I suggest you have a look at how memory mapped m5ops are implemented: https://github.com/gem5/gem5/blob/develop/src/arch/arm/mmu.cc#L185
If the memory reference lies within a specific address range (m5opRange) the memory access is replaced by the local accessor callback (recorded in the Request object with the setLocalAccessor method) This callback is supported by every cpu model; it accepts the TC as a parameter and returns the number of Cycles needed to execute the pseudo op. This means the following 1. If you just care about setting up the overall execution time of your custom instruction, you can implement it by returning a different number of Cycles 2. If you want to model the instruction differently, you can reuse this mechanism to provide CPU type visibility to your guest application. You could ass a pseudo op which is getting the CPU ptr from the TC ptr, dynamic casting it to KVMCpu to check if we are in KVM mode and return 1 in KVM mode, 0 otherwise Another option could be to implement your instruction in the Arm HINT space and hope your host doesn’t complain when the instruction is executed in KVM mode and it treats it as a NOP instead Kind regards Giacomo From: Pedro Becker via gem5-users <gem5-users@gem5.org> Date: Friday, 26 November 2021 at 14:43 To: gem5-users@gem5.org <gem5-users@gem5.org> Cc: Pedro Becker <pe...@ac.upc.edu> Subject: [gem5-users] Re: Decisions when adding new instructions: accuracy and kvm support Hi Giacomo, First of all, thanks for your time answering the question. Your assumption about KVM is correct. I just use it to fast-forward, and I do not need to execute the instruction I want to implement in KVM mode. Long story short: the same code for the ROI is executed during the fast-forwarding phase. Do you know if it's possible to capture the CPU type that gem5 code is running, from the application? This way I could manage to generate checkpoints with KVM using a functionally equivalent code that does not use my new instruction, and when I restore with a gem5 CPU, the new instruction is used. Alternatively, perhaps, I can capture the "unimplemented instruction" from the application, and in that case, call a functionally equivalent code? I'm not sure if the CPU will let me continue the execution when the unimplemented instruction is found (with KVM), though. There should be some way to capture this kind of exception I guess... If that is not a possible solution, then I'd have to run as many simulations as checkpoints I want (if I'm not mistaken one can go from KVM to gem5 CPU, but not go back to KVM), adapting the code to run up until the desired checkpoint time and changing some control variable so that my new instruction starts to be used. Although this is doable, it would be a little bit inconvenient as I take tens of checkpoints. Any thoughts about these alternatives? I'll probably have to explore/try them anyway, but any hints on where to start are helpful. _______________________________________________ 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
