From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH 1/1] KVM: Fix potentially recursively get kvm lock Date: Wed, 13 May 2009 14:43:49 +0300 Message-ID: <20090513114349.GW18554@redhat.com> References: <200905121705.53176.sheng.yang@intel.com> <1242120729-2280-1-git-send-email-sheng@linux.intel.com> <20090512115524.GB10901@amt.cnet> <200905122213.36833.sheng.yang@intel.com> <20090512143021.GB12888@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Yang, Sheng" , Avi Kivity , Alex Williamson , kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx2.redhat.com ([66.187.237.31]:40409 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759599AbZEMLnv (ORCPT ); Wed, 13 May 2009 07:43:51 -0400 Content-Disposition: inline In-Reply-To: <20090512143021.GB12888@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, May 12, 2009 at 11:30:21AM -0300, Marcelo Tosatti wrote: > On Tue, May 12, 2009 at 10:13:36PM +0800, Yang, Sheng wrote: > > > > + mutex_unlock(&kvm->lock); > > > > > > assigned_dev list is protected by kvm->lock. So you could have another > > > ioctl adding to it at the same time you're searching. > > > > Oh, yes... My fault... > > > > > Could either have a separate kvm->assigned_devs_lock, to protect > > > kvm->arch.assigned_dev_head (users are ioctls that manipulate it), or > > > change the IRQ injection to use a separate spinlock, kill the workqueue > > > and call kvm_set_irq from the assigned device interrupt handler. > > > > Peferred the latter, though needs more work. But the only reason for put a > > workqueue here is because kvm->lock is a mutex? I can't believe... If so, I > > think we had made a big mistake - we have to fix all kinds of racy problem > > caused by this, but finally find it's unnecessary... > > One issue is that kvm_set_irq can take too long while interrupts are > blocked, and you'd have to disable interrupts in other contexes that > inject interrupts (say qemu->ioctl(SET_INTERRUPT)->...->), so all i can > see is a tradeoff. > > > > But the interrupt injection path seems to be pretty short and efficient > to happen in host interrupt context. > > > > Avi, Gleb? > Interrupt injection path also use IRQ routing data structures so access to them should be protected by the same lock. And of cause in kernel device (apic/ioapic/pic) mmio is done holding this lock so interrupt injection cannot happen in parallel with device reconfiguration. May be we want more parallelism here. > > Maybe another reason is kvm_kick_vcpu(), but have already fixed by you. > > Note you tested the spinlock_irq patch with GigE and there was no > significant performance regression right? > > > > > Continue to check the code... > > > > -- > > regards > > Yang, Sheng > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb.