Florian Hofhammer <florian.hofham...@epfl.ch> writes:
> 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?
I think to read the PC we would just need to make sure we properly
resolve it - internally QEMU does this for faults with:
tb = tcg_tb_lookup(retaddr);
cpu_restore_state_from_tb(cpu, tb, retaddr);
where retaddr is the address of the translated code. We just need to
special case PC handling in the read path.
> 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?
No need - we just need to exit the loop via cpu_loop_exit_restore() and
the code will do the right thing. However we probably don't want to
trigger that via register write as we would surprise the plugin -
especially if there are other hooks still to run. So we would want an
explicit helper to do it.
>
> Thanks,
> Florian
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
