Hi, > -----Original Message----- > From: Paolo Bonzini [mailto:[email protected]] > Sent: Monday, May 12, 2014 5:58 PM
> Perhaps we can check for cases where only the address is changing, and > poke at an existing struct kvm_kernel_irq_routing_entry without doing > any RCU synchronization? > > As long as kvm_set_msi_irq only reads address_lo once, it should work. > > VHOST_SET_MEM_TABLE is a different problem. What happens in userspace > that leads to calling that ioctl? Can we remove it altogether, or delay > it to after the destination has started running? > I thought this approach is a little different from the original, as eliminating synchronize_rcu() means when the KVM_SET_GSI_ROUTING ioctl returns, CPUs that using old irq routing table may still running, and thus when vCPU in VM done setting CPU affinity, other vCPUs in VM may receive stale IRQs. But since in the original code, kvm_set_msi()->kvm_irq_delivery_to_apic()->...->__apic_accept_irq() may only sets vCPU's LAPIC, and kvm_vcpu_kick(), which means destination vCPUs may get scheduled to run after vCPU setting IRQ affinity get returned, thus receiving old stale IRQs. So thanks for the suggestion, I'll try it. And VHOST_SET_MEM_TABLE ioctl comes from vhost_dev_start() in QEMU when migration destination starts devices. Best regards, -Gonglei
