[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Wed, 2013-06-26 at 12:10 +0100, Stefano Stabellini wrote:
> On Wed, 26 Jun 2013, Ian Campbell wrote:
> > On Tue, 2013-06-25 at 19:38 +0100, Stefano Stabellini wrote:
> > > > > If that is the case, this can only happen once, right?  In that case
> > > > > rather than an atomic_t we could just have a bit in the status field I
> > > > > proposed before. It should be enough for us to keep track of the case
> > > > > when the irq is supposed to stay high even after the guest EOIs it. 
> > > > > (Of
> > > > > course that means that we need to re-inject it into the guest).
> > > > 
> > > > 
> > > > For the timer yes. I wonder, what happen if Xen receive an SGI (for
> > > > instance SCHEDULE ipi) twice, does Xen must re-inject it multiple times?
> > > 
> > > I don't think it can happen with anything but the vtimer: in order for
> > > the scenario above to happen it takes an irq that is EOId in the
> > > hardware before the guest EOIs it.
> > > 
> > > SGIs are completely "emulated", there is not an hardware irq
> > > corresponding to them. From the Xen point of view the SGI is inflight
> > > exactly and only from the moment the first vcpu sends it, to the point
> > > when the receiving vcpu EOIs it.
> > 
> > Are we talking about real SGIs (passed by Xen between physical
> > processors) or fake SGIs (emulated between virtual processors)?
> 
> I was talking about fake SGIs

I think Julien was talking about real ones (the Xen schedule IPI).

Ian.



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.