From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [RFC] create a single workqueue for each vm to update vm irq routing table Date: Tue, 26 Nov 2013 14:47:59 +0100 Message-ID: <5294A68F.6060301@redhat.com> References: <52949847.6020908@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Zhanghaoyu (A)" , KVM , "qemu-devel@nongnu.org" , Gleb Natapov , "Michael S. Tsirkin" , Eric Blake , Luonengjun , "Huangweidong (C)" , "Jinxin (F)" , Zanghongyong To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:1285 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756777Ab3KZNsL (ORCPT ); Tue, 26 Nov 2013 08:48:11 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Il 26/11/2013 14:18, Avi Kivity ha scritto: > >> I don't think a workqueue is even needed. You just need to use call_rcu >> to free "old" after releasing kvm->irq_lock. >> >> What do you think? > > Can this cause an interrupt to be delivered to the wrong (old) vcpu? 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. There is still the problem that Gleb pointed out, though. Paolo > The way Linux sets interrupt affinity, it cannot, since changing the > affinity is (IIRC) done in the interrupt handler, so the next interrupt > cannot be in flight and thus pick up the old interrupt routing table. > > However it may be vulnerable in other ways. > >