Re: [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8 Model

[Julien Grall <julien.grall@linaro.org>]

Hi,

On 25/11/14 17:44, Julien Grall wrote:
> ARMv8 model may not disable correctly the timer interrupt when Xen
> context switch to an idle vCPU. Therefore Xen may receive a spurious
> timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
> when trying to inject the interrupt with the following stack trace.
> 
> (XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
> (XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
> (XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
> (XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
> (XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
> (XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
> (XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
> (XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
> (XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
> (XEN)    [<000000000022482c>] schedule+0x684/0x6d0
> (XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
> (XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
> (XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
> (XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
> (XEN)    [<0000000000000001>] 0000000000000001
> 
> While we receive spurious virtual timer interrupt, this could be safely
> ignore for the time being. A proper fix need to be found for Xen 4.6.

Thanks to ARM, they found the root of the problem. When the timer
interrupt is edge-triggered, disabling the timer output signal, the
state of the interrupt won't change in the GIC.

I propose to reword the commit message into:

xen/arm: Handle platforms with edge-triggered virtual timer

Some platforms (such as the ARMv8 model) uses edge-triggered interrupt
for the virtual timer. Even if the timer output signal is masked in the
context switch, the GIC will keep track that of any raised interrupt
while the IRQs has been disabled. As soon as the IRQs are re-enabled,
the virtual interrupt timer will be injected to Xen.

The interrupt handler doesn't except to the receive the IRQ and will
crash if an idle vCPU is running:

(XEN)    [<0000000000228388>] _spin_lock_irqsave+0x28/0x94 (PC)
(XEN)    [<0000000000228380>] _spin_lock_irqsave+0x20/0x94 (LR)
(XEN)    [<0000000000250510>] vgic_vcpu_inject_irq+0x40/0x1b0
(XEN)    [<000000000024bcd0>] vtimer_interrupt+0x4c/0x54
(XEN)    [<0000000000247010>] do_IRQ+0x1a4/0x220
(XEN)    [<0000000000244864>] gic_interrupt+0x50/0xec
(XEN)    [<000000000024fbac>] do_trap_irq+0x20/0x2c
(XEN)    [<0000000000255240>] hyp_irq+0x5c/0x60
(XEN)    [<0000000000241084>] context_switch+0xb8/0xc4
(XEN)    [<000000000022482c>] schedule+0x684/0x6d0
(XEN)    [<000000000022785c>] __do_softirq+0xcc/0xe8
(XEN)    [<00000000002278d4>] do_softirq+0x14/0x1c
(XEN)    [<0000000000240fac>] idle_loop+0x134/0x154
(XEN)    [<000000000024c160>] start_secondary+0x14c/0x15c
(XEN)    [<0000000000000001>] 0000000000000001

The proper solution would be context/switching the virtual interrupt
state at the GIC level. This would also avoid masking the output signal
and requires specific handling in the guest OS.

Sadly, this solution require some refactoring which would miss the Xen
4.5 release.

For now implement a temporary solution which ignore the interrupt when
the idle VCPU is running.

Regards,

-- 
Julien Grall