On 5/28/21 1:15 PM, Luis Fernando Fujita Pires wrote:
From: Richard Henderson <richard.hender...@linaro.org>
More completely, update the CPU state with any information that has been
assumed constant. For most guests, this is just the PC. But e.g. for hppa
this is both iaoq.f (cip) and iaoq.b (nip).
It is very much up to the guest to determine the set of data that is present in
cpu_get_tb_cpu_state, and what can be assumed across the break.
I’m not sure I understand what “assumed constant” means in this context.
The pc of the branch destination is a constant, for instance.
As would be the enabled instruction set (consider arm's blx, which toggles
between arm and thumb isa).
Would
it be fair to say that step 2 should update any CPU state information that is
required by the main loop to correctly locate and execute the next TB, but not
anything that would be needed if we were to jump directly from step 1 to the
first
instruction in the next TB without going through the main loop?
The information written in step 2, omitted by step 1, must be inferable from
cpu_get_tb_cpu_state (via tcg_ops->synchronize_from_tb) and from cpu_restore_state.
One of the two forms is how we return to the main loop after escaping from the
chain of TB via interrupt or exception, respectively.
r~
