[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |