From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 05/10] KVM: Merge MSI handling to kvm_set_irq Date: Tue, 30 Dec 2008 19:26:56 +0800 Message-ID: <200812301926.57266.sheng@linux.intel.com> References: <1230616562-18113-1-git-send-email-sheng@linux.intel.com> <200812301900.58066.sheng@linux.intel.com> <495A0108.7080606@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mga09.intel.com ([134.134.136.24]:34367 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751510AbYL3L1A (ORCPT ); Tue, 30 Dec 2008 06:27:00 -0500 In-Reply-To: <495A0108.7080606@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Tuesday 30 December 2008 19:07:52 Avi Kivity wrote: > Sheng Yang wrote: > >>> + mutex_lock(&kvm->gsi_msg_lock); > >> > >> The lock is already taken here? > > > > Um? For gsi_msg_lock? > > Sorry, my mistake. Will have to get used to all those locks. > > Is there a way to avoid the lock? We're starting to complicate things... Well, one list, one lock... But it's not very performance affect one, so maybe I can try kvm->lock... > > >> This looks very messy. Would be better to have the in-kernel irq > >> structure contain a (*set_level)() callback that can take the > >> appropriate action. > > > > You means this part which would merged with ioapic, or something else? > > At the very least, separated into functions. > > At best, kvm_set_irq() should become generic and just invoke callbacks > supplied by the irqchip (pit, ioapic, msi). OK, I would separate it first. Callback function, a little later... -- regards Yang, Sheng