[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/arm: Handle platforms with edge-triggered virtual timer
On Tue, 2014-12-02 at 14:08 +0000, Julien Grall wrote: > 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). Are we sure there is no race here where the software timer doesn't fire because it appears to be in the past or something? That would correspond to the sequence: disable interrupts h/w timer expires, interrupt raised but masked calculate timeout for s/w timeout => -ve. Perhaps Xen s/w timers in the past fire immediately? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |