Re: [Xen-devel] ARM Generic Timer interrupt

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

>  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...

Ian.


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