On 05/08/2025 16:16, Alex Bennée wrote:
Another option would be to have a set_pc function that would restart
the execution at new PC. Then the vcpu_syscall_cb callback could set
the PC to post the syscall with whatever state it wants to set up.
Such a set_pc functionality is already covered with the register write
API, as long as I have a handle to the PC register, right? Please do
correct me if I'm misunderstanding something here!
Ahh we should make that clear. It requires special handling as the PC
isn't automatically updated every instruction. For analysis this isn't a
problem as the TB itself knows the vaddr of each instruction so can save
it if it wants.
Currently if you write to the PC it won't change flow - and it will
likely be reset as we exit the syscall.
c.f. https://gitlab.com/qemu-project/qemu/-/issues/2208
Thanks for the clarification, I haven't fully thought the implications
of updating the PC on the jited code through.
Do I understand correctly that this would likely require hooking into
the TCG in a way so that the target address of this set_pc function gets
retranslated? While I've dug into the QEMU code quite a bit already, I'm
not sure I'm familiar enough with the TCG internals to be able to tell
whether such a set_pc function could determine the address of an
(arbitrary) already translated block. I.e., if the target PC is not just
the next instruction after the syscall, can QEMU determine whether the
target address has already been translated and if yes, where the
generated code actually is located?
Thanks,
Florian
