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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
