From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH] xen/arm: Handle platforms with edge-triggered virtual timer Date: Tue, 02 Dec 2014 14:08:27 +0000 Message-ID: <547DC7DB.5040305@linaro.org> References: <1417187826-5491-1-git-send-email-julien.grall@linaro.org> <1417528456.24320.37.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvo81-000485-Jl for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:08:33 +0000 Received: by mail-wi0-f176.google.com with SMTP id ex7so28174348wid.3 for ; Tue, 02 Dec 2014 06:08:31 -0800 (PST) In-Reply-To: <1417528456.24320.37.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com List-Id: xen-devel@lists.xenproject.org Hi Ian, On 02/12/14 13:54, Ian Campbell wrote: > On Fri, 2014-11-28 at 15:17 +0000, Julien Grall wrote: >> Some platforms (such as Xgene and ARMv8 models) use an 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 interrupts raised >> while IRQs are disabled. As soon as IRQs are re-enabled, the virtual >> interrupt timer will be injected to Xen. >> >> If an idle vVCPU was scheduled next then the interrupt handler doesn't >> expect to the receive the IRQ and will crash: >> >> (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 is to context switch the virtual interrupt state at >> the GIC level. This would also avoid masking the output signal which >> requires specific handling in the guest OS and more complex code in Xen >> to deal with EOIs, and so is desirable for that reason too. >> >> Sadly, this solution requires some refactoring which would not be >> suitable for a freeze exception for the Xen 4.5 release. >> >> For now implement a temporary solution which ignores the virtual timer >> interrupt when the idle VCPU is running. >> > > When we reschedule the vcpu which caused the spurious interrupt, the IRQ > will definitely trigger again for real, right? Xen arms a timer when the domain is saved. As we received an unexpected interrupt that means the timer expires which will make Xen injected the virtual timer interrupt (see virt_timer_expired). >> Signed-off-by: Julien Grall > > Acked-by: Ian Campbell > > I'll defer applying until you've said Yes to the above question. > >> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c >> index a6436f1..471d7a9 100644 >> --- a/xen/arch/arm/time.c >> +++ b/xen/arch/arm/time.c >> @@ -169,6 +169,19 @@ static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs) >> >> static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs) >> { >> + /* >> + * Edge-triggered interrupt can be used for the virtual timer. Even > > "interrupts" > >> + * if the timer output signal is masked in the context switch, the >> + * GIC will keep track that of any interrupts raised while IRQS as > > s/as/are/ > > I'll fix those on commit. Thanks! Regards, -- Julien Grall