From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table Date: Tue, 26 Nov 2013 15:46:57 +0100 Message-ID: <5294B461.5000405@redhat.com> References: <52949847.6020908@redhat.com> <5294A68F.6060301@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , "Huangweidong (C)" , Gleb Natapov , KVM , "Michael S. Tsirkin" , "Jinxin (F)" , "Zhanghaoyu (A)" , Luonengjun , "qemu-devel@nongnu.org" , Zanghongyong To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58744 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754797Ab3KZOrK (ORCPT ); Tue, 26 Nov 2013 09:47:10 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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"). If you eliminate the synchronize_rcu, new interrupts would see the new routing table, while interrupts already in flight will get a dangling pointer. Paolo