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:23 +0100, Stefano Stabellini wrote:
> > On Wed, 26 Jun 2013, Ian Campbell wrote:
> > > On Wed, 2013-06-26 at 12:08 +0100, Stefano Stabellini wrote:
> > > > On Wed, 26 Jun 2013, Ian Campbell wrote:
> > > > > On Tue, 2013-06-25 at 17:58 +0100, Stefano Stabellini wrote:
> > > > > > On Tue, 25 Jun 2013, Ian Campbell wrote:
> > > > > > > On Tue, 2013-06-25 at 00:04 +0100, Julien Grall wrote:
> > > > > > > > From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
> > > > > > > > 
> > > > > > > > For guest's timers (both virtual and physical), Xen will inject 
> > > > > > > > virtual
> > > > > > > > interrupt. Linux handles timer interrupt as:
> > > > > > > 
> > > > > > > We should be wary of developing things based on the way which 
> > > > > > > Linux
> > > > > > > happens to do things. On x86 we have several time modes, which 
> > > > > > > can be
> > > > > > > selected based upon guest behaviour (described in
> > > > > > > docs/man/xl.cfg.pod.5). Do we need to do something similar here?
> > > > > > > 
> > > > > > > >   1) Receive the interrupt and ack it
> > > > > > > >   2) Handle the current event timer
> > > > > > > >   3) Set the next event timer
> > > > > > > >   4) EOI the interrupt
> > > > > > > > 
> > > > > > > > It's unlikely possible to reinject another interrupt before
> > > > > > > 
> > > > > > > I can't parse this sentence. "unlikely to be possible" perhaps? 
> > > > > > > but I'm
> > > > > > > not sure if that is what you meant.
> > > > > > > 
> > > > > > > > the previous one is EOIed because the next deadline is shorter 
> > > > > > > > than the time
> > > > > > > > to execute code until EOI it.
> > > > > > > 
> > > > > > > If we get into this situation once is there any danger that we 
> > > > > > > will get
> > > > > > > into it repeatedly and overflow the count?
> > > > > > > 
> > > > > > > Overall I'm not convinced this is the right approach to get the
> > > > > > > behaviour we want. Isn't this interrupt level triggered, with the 
> > > > > > > level
> > > > > > > being determined by a comparison of two registers? IOW can't we
> > > > > > > determine whether to retrigger the interrupt or not by examining 
> > > > > > > the
> > > > > > > state of our emulated versions of those registers? A generic 
> > > > > > > mechanism
> > > > > > > to callback into the appropriate emulator on EOI plus a little 
> > > > > > > bit of
> > > > > > > logic in the vtimer code is all it ought to take.
> > > > > > 
> > > > > > AFAICT this what could happen:
> > > > > > 
> > > > > > - vtimer fires
> > > > > > - xen mask the vtimer
> > > > > > - xen adds the vtimer to the LR for the guest
> > > > > > - xen EOIs the vtimer
> > > > > 
> > > > > This step is Xen deprioritises the interrupt (by writing to the 
> > > > > GICD_DIR
> > > > > register)...
> > > > > 
> > > > > > - the guest receive 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 eoi the vtimer
> > > > > 
> > > > > ... and the actual Xen EOI only happens here in response to the
> > > > > maintenance interrupt resulting from the guests EOI.
> > > > > 
> > > > > (or maybe I've misunderstood what you mean by "EOI the vtimer")
> > > > 
> > > > The vtimer is a Xen irq that injects an irq into the guest from the Xen
> > > > interrupt handler. It's not a guest irq.
> > > > See xen/arch/arm/time.c:vtimer_interrupt.
> > > 
> > > OK, so what does it mean to "EOI" that timer?
> >  
> > By "xen EOIs the vtimer" I meant Xen EOIs the vtimer interrupt in the
> > real hardware.
> 
> Oh right, for some reason I thought this was driven off Xen timer
> infrastructure, rather than being an actual interrupt.
> 
> 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

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