On 11/26/2013 05:03 PM, Gleb Natapov wrote:
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().
Consider this guest code:
write msi entry, directing the interrupt away from this vcpu
nop
memset(&idt, 0, sizeof(idt));
Currently, this code will never trigger a triple fault. With the change
to call_rcu(), it may.
Now it may be that the guest does not expect this to work (PCI writes
are posted; and interrupts can be delayed indefinitely by the pci
fabric), but we don't know if there's a path that guarantees the guest
something that we're taking away with this change.
--
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
