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"). If you eliminate the synchronize_rcu, new interrupts would see the new routing table, while interrupts already in flight will get a dangling pointer. Paolo -- 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
