From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlKRX-0000w1-3b for qemu-devel@nongnu.org; Tue, 26 Nov 2013 10:20:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlKRQ-000716-RA for qemu-devel@nongnu.org; Tue, 26 Nov 2013 10:20:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:6317) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlKRQ-00070s-9M for qemu-devel@nongnu.org; Tue, 26 Nov 2013 10:20:44 -0500 Message-ID: <5294BC3B.6070902@redhat.com> Date: Tue, 26 Nov 2013 16:20:27 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <52949847.6020908@redhat.com> <5294A68F.6060301@redhat.com> <5294B461.5000405@redhat.com> <5294B634.4050801@cloudius-systems.com> <20131126150357.GA20352@redhat.com> In-Reply-To: <20131126150357.GA20352@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Avi Kivity , "Huangweidong (C)" , KVM , "Michael S. Tsirkin" , "Zhanghaoyu (A)" , Luonengjun , "qemu-devel@nongnu.org" , Zanghongyong , Avi Kivity , "Jinxin (F)" Il 26/11/2013 16:03, Gleb Natapov ha scritto: >>>> > >>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 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