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: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.
By "the guest eoi the vtimer" I meant the guest EOIs the virtual
interrupt that we injected into the guest.

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