From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXvUz-0003KC-Nn for qemu-devel@nongnu.org; Tue, 06 Dec 2011 08:56:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXvUu-0005xX-0t for qemu-devel@nongnu.org; Tue, 06 Dec 2011 08:55:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXvUt-0005xK-MM for qemu-devel@nongnu.org; Tue, 06 Dec 2011 08:55:51 -0500 Message-ID: <4EDE1EE3.5090008@redhat.com> Date: Tue, 06 Dec 2011 15:55:47 +0200 From: Avi Kivity MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 00/16] uq/master: Introduce basic irqchip support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl On 12/06/2011 02:58 PM, Jan Kiszka wrote: > In this revision, I'm now trying the approach of backend/frontend > split-ups for the affected IRQ chips. That means we keep a single qdev > device description but fork off specific logic early during device init. > The backends support this by providing hooks that user space and KVM > models can implement differently. > > The result is slightly larger and comes with the not really beautiful > ioapic.kvm_gsi_base property but should otherwise meet expectations. > > Comments? Looks good to me, much nicer than the previous approaches. I'll wait a bit for more reviews though. > PS: Series is still against old uq/master, therefore containing patches > that took/will take different routes. I just pushed a rebased uq/master. In the future, either ping me or just base on upstream (which uq/master supposedly tracks). -- error compiling committee.c: too many arguments to function