On 9/22/26 10:58, Mikulas Patocka wrote:
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.
Could well be. Do you have a reliable reproducer? Or is this a "run
the container and things eventually fail" sort of thing?
Logging guest state at the point your revert hook fires could be
informative...
BTW. what happens with synchronous signals inside the TB? (i.e. SIGSEGV
due to writing into a write-protected page)
Synchronous signals like that exit the translation block right away,
leading to the signal being delivered.
r~
