Re: [PATCH] accel/tcg: Call tcg_tb_insert() for one-insn TBs

[Peter Maydell]

On Thu, 16 Jan 2025 at 11:48, Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> On Thu, 2025-01-16 at 11:06 +0000, Peter Maydell wrote:
> > The original reported problem here seems to me like it's a
> > problem with whatever target's frontend code this is.
> > This is a single instruction TB, so either:
> >  * the generated code for it completes the insn without
> >    raising an exception (no problem)
> >  * the generated code for it should raise an exception
> >    without having modified the CPU state (so there would
> >    be nothing to do for restore_state_to_opc)
> >
> > It sounds like the target is generating code which does
> > something like:
> >  * do part of the instruction, including updating some of
> >    the CPU state
> >  * then decide it needs to raise an exception, and rely on
> >    the restore_state_to_opc handling to undo the state updates
> >    it did previously
> >
> > The assumption of the "throwaway single insn TB" is that
> > you don't do that (i.e. that restore_state_to_opc is only
> > there for the benefit of multi-insn TBs).

> The problem is not a partial state update in an instruction, but rather
> that on some targets restore_state_to_opc is more than just a
> "restore" - it is also "prepare for handling an exception", i.e.:
>
> - arm: exception.syndrome
> - hppa: unwind_breg, psw_n
> - mips: btarget
> - openrisc: ppc
> - riscv: excp_uw2
> - s390x: int_pgm_ilen
>
> Some of these may be wrong due to unfamiliarity with the respective
> architectures, sorry - but this illustrates the idea.

Ah, yes, thanks for the clear explanation. The "throw away
the TB" design didn't consider that (or vice-versa).

thanks
-- PMM