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

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





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


 


Rackspace

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