Re: ARM Generic Timer interrupt

[Julien Grall <julien.grall@linaro.org>]

On 05/28/2014 12:34 PM, Ian Campbell wrote:
> On Wed, 2014-05-28 at 12:32 +0100, Julien Grall wrote:
>> On 05/28/2014 11:10 AM, Ian Campbell wrote:
>>> On Tue, 2014-05-27 at 13:11 +0100, Stefano Stabellini wrote:
>>>>> But, I have question:
>>>>> Should the Hypervisor masks virtual timer IRQ on his own?
>>>>> It is a guest's resource and the guest itself should decide what to do.
>>>>> For example, I see that Linux Kernel (3.8) sets and clears timer interrupt mask by itself.
>>>>
>>>> In principle I agree with you that the vtimer is a guest resource.
>>>> However in practice if we don't mask the irq we can easily get into an
>>>> interrupt storm situation: if the guest doesn't handle the interrupt
>>>> immediately we could keep receiving the vtimer irq in the hypervisor and
>>>> busy loop around it.
>>>
>>> Do we not do a priority drop on the interrupt when we receive it, so we
>>> won't get any more interrupts from the timer until it acks the
>>> interrupt?
>>
>> The timer interrupt is acked directly by Xen. We can't wait the guest
>> VCPU as EOI the interrupt because the guest may have move to another
>> pCPU by this time.
> 
> Surely we can arrange to handle that though. The way we currently handle
> the timer stuff always seemed suboptimal to me.

If so, no need to request a maintenance interrupt (see Stefano's patch).
And handle EOI during context switch.

This will be slower than the current solution (which is also used by
KVM). I think it's fine to make a specific case for the virt timer in
the guest OS.

Regards,

-- 
Julien Grall