Re: [PATCH] docs/devel: Explain in more detail the TB chaining mechanisms

[Richard Henderson]

On 5/28/21 1:15 PM, Luis Fernando Fujita Pires wrote:
> From: Richard Henderson <richard.henderson@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~