Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

[Gleb Natapov <gleb@redhat.com>]

On Tue, Nov 26, 2013 at 04:54:44PM +0200, Avi Kivity wrote:
> On 11/26/2013 04:46 PM, Paolo Bonzini wrote:
> >Il 26/11/2013 15:36, Avi Kivity ha scritto:
> >>     No, this would be exactly the same code that is running now:
> >>
> >>             mutex_lock(&kvm->irq_lock);
> >>             old = kvm->irq_routing;
> >>             kvm_irq_routing_update(kvm, new);
> >>             mutex_unlock(&kvm->irq_lock);
> >>
> >>             synchronize_rcu();
> >>             kfree(old);
> >>             return 0;
> >>
> >>     Except that the kfree would run in the call_rcu kernel thread instead of
> >>     the vcpu thread.  But the vcpus already see the new routing table after
> >>     the rcu_assign_pointer that is in kvm_irq_routing_update.
> >>
> >>I understood the proposal was also to eliminate the synchronize_rcu(),
> >>so while new interrupts would see the new routing table, interrupts
> >>already in flight could pick up the old one.
> >Isn't that always the case with RCU?  (See my answer above: "the vcpus
> >already see the new routing table after the rcu_assign_pointer that is
> >in kvm_irq_routing_update").
> 
> With synchronize_rcu(), you have the additional guarantee that any
> parallel accesses to the old routing table have completed.  Since we
> also trigger the irq from rcu context, you know that after
> synchronize_rcu() you won't get any interrupts to the old
> destination (see kvm_set_irq_inatomic()).
We do not have this guaranty for other vcpus that do not call
synchronize_rcu(). They may still use outdated routing table while a vcpu
or iothread that performed table update sits in synchronize_rcu().

--
			Gleb.