[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



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 <julien.grall@xxxxxxxxxx>
> 
> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> 
> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.