[prev in list] [next in list] [prev in thread] [next in thread]
List: xen-cvs
Subject: [Xen-changelog] [xen stable-4.4] xen/arm: Handle platforms with edge-triggered virtual timer
From: patchbot () xen ! org
Date: 2014-12-14 11:55:25
Message-ID: E1Y07ll-0007dI-6d () xenbits ! xen ! org
[Download RAW message or body]
commit af73321f101962c69d48daf21bfe09b87a49b459
Author: Julien Grall <julien.grall@linaro.org>
AuthorDate: Fri Nov 28 15:17:06 2014 +0000
Commit: Ian Campbell <ian.campbell@citrix.com>
CommitDate: Wed Dec 10 14:08:55 2014 +0000
xen/arm: Handle platforms with edge-triggered virtual timer
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.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- tweaked some wording in the comment ]
(cherry picked from commit f688aec47c452d6aef382739d0781735672ef995)
---
xen/arch/arm/time.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 5374bf7..170d1cd 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -213,6 +213,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 interrupts can be used 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
+ * will be injected to Xen.
+ *
+ * If an IDLE vCPU was scheduled next then we should ignore the
+ * interrupt.
+ */
+ if ( unlikely(is_idle_vcpu(current)) )
+ return;
+
current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq, 1);
--
generated by git-patchbot for /home/xen/git/xen.git#stable-4.4
_______________________________________________
Xen-changelog mailing list
Xen-changelog@lists.xen.org
http://lists.xensource.com/xen-changelog
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic