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

Reply via email to