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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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")

Ian.


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