qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] vhost: Can we change synchronize_rcu to call_rcu


From: Gonglei (Arei)
Subject: Re: [Qemu-devel] [RFC] vhost: Can we change synchronize_rcu to call_rcu in vhost_set_memory() in vhost kernel module?
Date: Tue, 13 May 2014 07:01:46 +0000

Hi,

> -----Original Message-----
> From: Paolo Bonzini [mailto:address@hidden
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]