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

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