From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH for-4.5] xen/arm: Fix virtual timer on ARMv8 Model Date: Thu, 27 Nov 2014 18:02:04 +0000 Message-ID: <5477671C.4010500@linaro.org> References: <1416937469-8162-1-git-send-email-julien.grall@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xu3ON-0008DI-1u for xen-devel@lists.xenproject.org; Thu, 27 Nov 2014 18:02:11 +0000 Received: by mail-wg0-f42.google.com with SMTP id z12so7118802wgg.29 for ; Thu, 27 Nov 2014 10:02:09 -0800 (PST) In-Reply-To: <1416937469-8162-1-git-send-email-julien.grall@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xenproject.org Cc: stefano.stabellini@citrix.com, tim@xen.org, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.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