Re: [Qemu-devel] ARM64 Interrupt handling on QEMU

[Peter Maydell]

On 15 March 2018 at 03:07, Brijen Raval <address@hidden> wrote:
> I am booting up a custom kernel on QEMU ARM64, upon completion of its
> initial boot up it looks like it enters the arch_idle() state
>
> I enabled the -d int logging to understand what is going on, I see the
> following repeated many times continuosly here after
>
> Taking exception 5 [IRQ]
> ...from EL1 to EL1
> ...with ESR 0x15/0x56000000
> ...with ELR 0xffffffff0000349c
> ...to EL1 PC 0xffffffff00008280 PSTATE 0x3c5
>
> Here's the dissassembly for the relevant piece of code:
>
>  ffffffff00003498 <arch_idle>:
>  arch_idle():
>  ../../kernel/arch/arm64/arch.cpp:182
>  ffffffff00003498:       d503207f        wfi
>  ffffffff0000349c:       d65f03c0        ret
>
> I am trying to understand what exceptions are occurring exactly when kernel
> is idle (timer?). According to above ELR is pointing to arch_idle(), but I
> believe "wfi" instruction would not be an IRQ but a sync abort which is
> handle differently right?

WFI is neither an IRQ nor an abort. It's just a hint to the CPU
that it doesn't need to execute any more instructions until the
next interrupt occurs. (It's a valid implementation for it to just
be a NOP.) QEMU does implement WFI to be "don't execute more insns
until the next interrupt", which is why you're seeing the ELR for
the interrupt generally being the ret insn: if the guest is mostly
idle and its idle loop includes a WFI then almost all the time an
incoming interrupt will find that the CPU was in the WFI insn.

Correctly written software will not ever issue a WFI unless it
has some mechanism for being woken up from it, which is typically
an outstanding interrupt, perhaps timer or an interrupt for
completed disk or network operation. For an SMP kernel it could also be
some other CPU sending this CPU an inter-processor-interrupt to
wake us up). "idle" for an OS just means "nothing to do right now".

> Also from ESR, it looks like a SVC instruction but if I am not wrong for
> IRQs ESRs are not updated (considered)

QEMU's logging prints the ESR value for all exceptions, even those
where architecturally the ESR is not updated. In those cases the
printed value can be ignored.

> One more thing, is there a way in QEMU I could find out what exception 5 is
> corresponding to?

The logging tells you:
> Taking exception 5 [IRQ]

Exception 5 is IRQ. (These numbers are all internal to QEMU, and
don't have any architectural or guest-visible relevance. They're
the EXCP_* constants defined at the top of target/arm/cpu.h.)

thanks
-- PMM