Re: [Xen-devel] [PATCH v6 2/5] xen/arm: inflight irqs during migration

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 24/06/14 12:57, Stefano Stabellini wrote:
> On Mon, 23 Jun 2014, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 23/06/14 17:37, Stefano Stabellini wrote:
> > > @@ -786,9 +837,14 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq)
> > >
> > >        spin_lock_irqsave(&v->arch.vgic.lock, flags);
> > >
> > > +    set_bit(GIC_IRQ_GUEST_QUEUED, &n->status);
> > > +    /* update QUEUED before MIGRATING */
> > > +    smp_wmb();
> > > +    if ( test_bit(GIC_IRQ_GUEST_MIGRATING, &n->status) )
> > > +        goto out;
> > Why do you kick the current VCPU here? It looks like useless because the 
> > migration will take care of it.
> With the physical follow virtual patch, the vcpu_unblock below is going
> to be mostly useless but harmless as vgic_vcpu_inject_irq is going to be called 
> on
> the pcpu running the destination vcpu. smp_send_event_check_mask won't be 
> called as
> v == current.
>
> On the other hand without that patch, the pcpu receiving the physical
> interrupt could be different from any of the pcpus running the vcpus
> involved in vcpu migration, therefore we would need the kick to wake up
> the destination vcpu.
If the MIGRATING bit is set it means that an IRQ is already inflight, 
and therefore gic_update_one_lr will take care of injecting this IRQ to 
the new VCPU by calling vgic_vcpu_inject_irq.
So kicking the new VCPU here is pointless and may unschedule another 
VCPU for nothing. The latter may be able to run a bit more.
With your patch #4 (physical IRQ follow virtual IRQ), there is a tiny 
range the VCPU may not run on the same pCPU where the physical IRQ as 
been routed. This is the case when the VCPU is unscheduled.
Regards,

--
Julien Grall

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