Re: [PATCH] target/arm/helper: Fix timer interrupt masking when HCR_EL2.E2H == 0

[Peter Maydell]

On Tue, 20 Aug 2024 at 12:30, Florian Lugou <florian.lugou@provenrun.com> wrote:
>
> > > $ aarch64-none-elf-gcc -ffreestanding -nostdlib -T 
> > > qemu/tests/tcg/aarch64/system/kernel.ld -o test test.S
> > >
> > > $ qemu-system-aarch64 \
> > >         -machine virt,secure=on,gic-version=3 \
> > >         -cpu cortex-a57 \
> > >         -kernel test \
> > >         -display none \
> > >         -semihosting
> > >
> > > $ # Exits after ~1s
> > >
> > > $ qemu-system-aarch64 \
> > >         -machine virt,secure=on,gic-version=3 \
> > >         -cpu cortex-a57 \
> > >         -kernel test \
> > >         -display none \
> > >         -semihosting \
> > >         -icount shift=0,sleep=off
> > >
> > > ... (hangs until QEMU is killed)
> >
> > For me, with QEMU commit 9eb51530c12ae645b, this test case
> > exits (doesn't hang) with both these command lines. Do you
> > still see this bug? I guess it's possible we fixed it in
> > the last month or so, though I can't see anything obviously
> > relevant in the git logs.
>
> Thank you for taking the time to test it.
>
> On my machine (Ubuntu 22.04), with QEMU configuration options
> "--target-list=aarch64-softmmu --enable-debug", running the provided test case
> with "-icount shift=0,sleep=off" still makes QEMU hang forever on commit
> 9eb51530c12ae645b.
>
> The issue was initially reported by a colleague of mine so I was hoping it 
> would
> be somehow reliably reproducible. But apparently it is not.

Somebody else reported a similar issue to this to me this week,
which reminded me of a different bug that we'd found and fixed
in the interim, which was enough of a hint that I figured out
why this wasn't reproducible for me.

This bug only reproduces if your QEMU binary isn't compiled
with slirp support (which will happen if your host system
doesn't have libslirp-dev or libslirp-devel installed).
If slirp is present then the usermode networking backend
will be present and it always has an active timer. Without
slirp, the problem manifests when there are no active timers.

You can also repro it on a with-slirp compile by adding
"-net none" to the command line.

I'll have a look at what the underlying bug is... thanks again
for the handy test case.

thanks
-- PMM