Re: [Xen-devel] [PATCH 2/5] xen/arm: Keep count of inflight interrupts

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 26 Jun 2013, Ian Campbell wrote:
> On Wed, 2013-06-26 at 12:50 +0100, Stefano Stabellini wrote:
> > On Wed, 26 Jun 2013, Ian Campbell wrote:
> 
> > > In that case my comments about deprioritisation and actual EOI happening
> > > later are correct, aren't they?
> > 
> > No, they are not. This is the full sequence of events, including
> > deprioritization and EOI:
> > 
> > - the vtimer interrupt fires
> > - xen deprioritizes the vtimer interrupt
> > - xen masks the vtimer interrupt
> > - xen adds the vtimer interrupt to the LR for the guest
> > - xen EOIs the vtimer interrupt
> > - the guest receives the vtimer interrupt
> > - the guest deprioritizes the vtimer interrupt
> > - the guest set the next deadline in the past
> > - the guest enables the vtimer
> > ## an unexpected vtimer interrupt is received by Xen but the current
> > ## one is still being serviced 
> > - the guest EOIs the vtimer interrupt
> 
> Is this particular to the handling of the vtimer interrupt? 

Yes


> In the
> normal case an interrupt which is injected into the guest isn't EOIed by
> Xen until the maintenance interrupt, isn't it?

Right


> But the vtimer is special
> because it isn't routed to the guest even though we do so via an
> orthogonal mechanism?

Yes


> Perhaps the solution here is a third type of interrupt alongside
> "for-xen" and "for-a-specific-guest" which is "for-current-guest"?

We could try but I did implement this strategy first and I ran into some
serious problems. It could have been because the vtimer emulation in the
FastModel had issues.

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