On Fri, 21 Jun 2024 at 15:07, Florian Lugou <florian.lu...@provenrun.com> wrote:
>
> On Thu, Jun 20, 2024 at 08:01:01PM +0100, Peter Maydell wrote:
> > On Thu, 20 Jun 2024 at 14:56, Florian Lugou <florian.lu...@provenrun.com>
> > wrote:
> > >
> > > On Thu, Jun 20, 2024 at 11:43:17AM +0100, Peter Maydell wrote:
> > > > For this timer check, we're doing I think the same thing as the
> > > > pseudocode AArch64.CheckTimerConditions(), which does:
> > > >
> > > > if (IsFeatureImplemented(FEAT_RME) && ss IN {SS_Root, SS_Realm} &&
> > > > CNTHCTL_EL2.CNTPMASK == '1') then
> > > > imask = '1';
> > > >
> > > > so I'm inclined to say that our current implementation in QEMU is
> > > > correct.
> > >
> > > Indeed. I got confused with the specification, my apologies.
> > >
> > > I am facing an issue with QEMU freezing waiting for a timer interrupt when
> > > running with -icount shift=0,sleep=off. Bissection has shown that the
> > > issue
> > > appeared with f6fc36deef6abcee406211f3e2f11ff894b87fa4.
> > >
> > > Further testing suggests that the issue may come from gt_recalc_timer.
> > > Calling
> > > gt_update_irq before timer_mod (as it was done before f6fc36deef6a)
> > > rather than
> > > at the end of the function solves the issue. Is it possible that timer_mod
> > > relies on cpu->gt_timer_outputs, which has not been modified at this
> > > point to
> > > reflect the timer triggering?
> >
> > I don't *think* it ought to care -- timer_mod() tells QEMU's timer
> > infrastructure when to schedule the next timer callback for,
> > and the gt_timer_outputs qemu_irqs tell the interrupt controller
> > that the interrupt lines have changed state.
> >
> > Do you have a reproduce case?
>
> I do:
(Sorry I didn't get back to you on this earlier.)
> $ 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.
thanks
-- PMM
