Hi Stefano, On 30/05/17 23:35, Stefano Stabellini wrote:
+ /* + * TODO: lookup currently-in-guest virtual IRQs and migrate them, + * as the locking may be fragile otherwise. + * This is not easy to do at the moment, but should become easier + * with the introduction of a per-IRQ lock. + */Sure but at least we can handle the inflight, but not in guest, case. It is just a matter of adding (withing the arch.vgic.lock locked region): if ( !list_empty(&p->lr_queue) ) { gic_remove_irq(old, p); clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status); list_del_init(&p->lr_queue); list_del_init(&p->inflight); spin_unlock_irqrestore(&old->arch.vgic.lock, flags); vgic_vcpu_inject_irq(new, irq); }
Please no more hardcoding of migration code. If we are going to support migration we should rework the current function vgic_migrate_irq to support LPIs.
But ... I don't see any drawback to not support this today. Per the specification, when you migrate an interrupt the only things you have to ensure if the pending interrupt only fire once either on the old or new vCPU.
IHMO, if the interrupt has already been queued then it is too late. We should aim at simplifying the code if there are no drawback to do it. In this case, what would be the drawback to leave pending on the old vCPU?
Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
