Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

[Zhanghaoyu (A)]

>>>>> > >>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().
>
>Avi's point is that, after the VCPU resumes execution, you know that no 
>interrupt will be sent to the old destination because kvm_set_msi_inatomic 
>(and ultimately kvm_irq_delivery_to_apic_fast) is also called within the RCU 
>read-side critical section.
>
>Without synchronize_rcu you could have
>
>    VCPU writes to routing table
>                                       e = entry from IRQ routing table
>    kvm_irq_routing_update(kvm, new);
>    VCPU resumes execution
>                                       kvm_set_msi_irq(e, &irq);
>                                       kvm_irq_delivery_to_apic_fast();
>
>where the entry is stale but the VCPU has already resumed execution.
>
If we use call_rcu()(Not consider the problem that Gleb pointed out 
temporarily) instead of synchronize_rcu(), should we still ensure this?

Thanks,
Zhang Haoyu

>If we want to ensure, we need to use a different mechanism for synchronization 
>than the global RCU.  QRCU would work; readers are not wait-free but only if 
>there is a concurrent synchronize_qrcu, which should be rare.
>
>Paolo