Re: [Xen-devel] ARM Generic Timer interrupt

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 28 May 2014, 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.

Aside from vcpu migration that we can obviously handle correctly, in
order to avoid the current "hack" we would need to introduce 2 vtimer
special cases in vgic.c and gic.c. Also even though I don't have any
numbers to prove it, I suspect that activating/deactivating the vtimer
irq at the GICD level all the time might be slower than just masking it
at the vtimer level.

So the tradeoff is: worse, slower hypervisor code but correctness of the
interface, or faster, leaner hypervisor code but a slightly worse guest
interface?
I don't know what the right answer is, but I am leaning toward the
second option.

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