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:37:12 +0100 Message-ID: <5385CA68.80903@linaro.org> References: <1401271857.26340.9.camel@kazak.uk.xensource.com> <5385C956.1000004@linaro.org> <1401276897.31647.2.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: <1401276897.31647.2.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 Cc: Oleksandr Tyshchenko , "xen-devel@lists.xen.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.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