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 13:11 +0100, Stefano Stabellini wrote:
> 
> > The patch uses GICD_ICENABLER to disable the timer because after the
> > desc->handler->end call, the vtimer can fire again unless properly
> > masked/deactivated. At the same time we need to call end otherwise we
> > won't be receiving other interrupts in Xen.
> > 
> > I guess an alternative implementation would introduce a special case in
> > do_IRQ, avoid calling desc->handler->end for the vtimer and only do
> > GICC[GICC_EOIR] = vtimer_irq to lower the priority, similarly to
> > IRQ_GUEST.
> 
> I was thinking that while the guest was running we would treat the
> vtimer IRQ exactly like IRQ_GUEST.
> 
> Then when we deschedule the vcpu if it has an unacked vtimer IRQ then we
> would ACK it and record that we have done so. When the vcpu is the
> rescheduled we would then need to mask the vtimer IRQ (in the gicd) and
> setup the LRs with a virtual interrupt such that we get a maintenance
> interrupt when the guest does EOI the interrupt. At that point we unmask
> and resume treating timers like IRQ_GUEST for the remainder of the
> timeslice.
> 
> The benefit is that much of the time we can treat the vtimer like any
> other h/w IRQ and avoid traps altogether.

yeah, this is exactly what I was trying to describe below


> >  We would then EOI the irq after receiving the maintenance
> > interrupt, but not in the maintenance interrupt handler, because we need
> > to EOI the maintenance interrupt first.   In addition it also needs
> > another special case in gic_save_state to EOI the vtimer interrupt if
> > the guest hasn't yet done so on vcpu save. And yet another special case
> > in gic_restore_state to deactivate the interrupt using GICD_ICENABLER,
> > because since the guest might not have handled it yet, it could fire
> > again continuously and we are not protected by the missing EOI anymore.
> > It doesn't sound better overall.
> 
> Better than what?
> 
> Obviously none of this is better than just mandating that guests expect
> the vtimer to be masked when it fires, like we do today...

True.
If we really had to go down this route I would still prefer my hacked-up
patch because I think it is easier to understand (at least to me).
But in any case I would advise to keep things as they are.

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