From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: ARM Generic Timer interrupt Date: Wed, 28 May 2014 12:32:38 +0100 Message-ID: <5385C956.1000004@linaro.org> References: <1401271857.26340.9.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1401271857.26340.9.camel@kazak.uk.xensource.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 , Stefano Stabellini Cc: Oleksandr Tyshchenko , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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. If so, you will lose the interrupt timer on this pCPU forever. Regards, -- Julien Grall