On Tue, 22 Sep 2026, Richard Henderson wrote:
> On 9/22/26 10:04, Mikulas Patocka wrote:
> > I looked at the sh4 translator and it seems that it already tries to make
> > sure that the full gUSA region is translated into one TB - i.e. there is
> > "ctx->base.max_insns = max_insns" in sh4_tr_init_disas_context - that will
> > override the value "1" that is supplied by cpu_exec_step_atomic. The
> > comments suggest that the author is aware of the fact that the gUSA region
> > must be completed atomically.
> >
> > So, the code that single-steps through the gUSA region is not needed.
> >
> > It seems that the misbehavior is caused by the fact that if we exit from
> > the gUSA TB early, we execute the rest of the region in non-exclusive
> > context.
> >
> > I simplified the patch, so that it adds just one method -
> > revert_uninterruptible. It tests whether we are in the unfinished gUSA
> > region, and if we are, it reverts PC and SP back to the beginning.
>
> What good does that do? You'll only restart the same block as before.
>
> Is this really the case where you're encountering
Without that patch, it deadlocks in 10-30 minutes. With the patch (either
version 1 or version 2 that I sent), it stays running overnight.
Maybe the bug is somewhere else and the patch just papers over it.
> > if (pc != pc_end + backup || max_insns < 2) {
> > /* This is a malformed gUSA region. Don't do anything special,
> > since the interpreter is likely to get confused. */
> > ctx->envflags &= ~TB_FLAG_GUSA_MASK;
>
> If you add an abort here, does it trigger?
I added the abort(). It deadlocked in 25 minutes, but didn't trigger it.
> > + /*
> > + * If we are interrupted in the middle of the gUSA region, we must
> > + * roll-back PC to the beginning of the region. Continuing halfway
> > + * through the region would break atomicity guarantees.
> > + *
> > + * If we are interrupted after the final write instruction (i.e.
> > + * cpu->env.pc == cpu->env.gregs[0]), we must not roll-back, because
> > + * the atomic write is already committed in the memory.
> > + */
> Just know that you *can't* be interrupted in the middle of a gUSA region.
> Signals will always be delayed until the end of the TranslationBlock.
>
> So this text is misleading at best.
Yes, I am not qemu expert.
BTW. what happens with synchronous signals inside the TB? (i.e. SIGSEGV
due to writing into a write-protected page)
Mikulas
