On Tue, 22 Sep 2026, Richard Henderson wrote:
> 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?
Download the Ajla programming language from
git clone git://repo.or.cz/ajla.git
(there is a mirror at https://www.github.com/mikulas-patocka/ajla.git)
(see the homepage at https://www.ajla-lang.cz/ )
Install the sh4 toolchain: gcc-sh4-linux-gnu (I use Debian Sid)
Install autoconf, automake, ed, make
Compile Ajla:
CC=sh4-linux-gnu-gcc CF="-DDEBUG_ENV" ./rebuild --disable-rwx-mappings
--disable-rwx-mappings is a workaround for another qemu bug - see
https://gitlab.com/qemu-project/qemu/-/work_items/2998
Download https://ajla-lang.cz/downloads/examples/advent-2023/18-2.ajla
Create an input file:
cat >18-small.txt <<EOF
R 6 (#70c710)
D 5 (#0dc571)
L 2 (#5713f0)
D 2 (#d2c081)
R 2 (#59c680)
D 2 (#411b91)
L 5 (#8ceee2)
U 2 (#caa173)
L 1 (#1b58a2)
U 2 (#caa171)
R 2 (#7807d2)
U 3 (#a77fa3)
L 2 (#015232)
U 2 (#7a21e3)
EOF
Run
while time /usr/src/git/qemu/build/qemu-sh4 ./ajla --nosave --tick=100
--thread-tick 18-2.ajla <18-small.txt; do date; done 2>&1 | tee lockup.log
Wait for several tens of minutes - it deadlocks on exit, after printing
the output "952408144115"
> Logging guest state at the point your revert hook fires could be
> informative...
Yes, I will look into it.
> > 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.
So, the TB can exit halfway through?
When I was analyzing the bug 2998, I found out that Qemu marks pages with
executed code as read-only. When the program writes into them, it
invalidates the translated code and marks the pages as read-write.
How does this interact with TBs exits? What happens if we write into a
read-only page in the middle of the TB?
Note that Ajla has JIT that generates sh4 code on the fly. But the option
--disable-rwx-mappings makes it store the generated code in separate pages
and not on the heap. So, I don't know if it can cause these problems.
Mikulas
