From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvvWh-00051m-Tz for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:07:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvvWd-0004v3-O1 for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:07:35 -0400 Received: from [199.232.76.173] (port=57212 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvvWd-0004ur-J2 for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:07:31 -0400 Received: from mail2.shareable.org ([80.68.89.115]:41136) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MvvWd-0004Hc-0W for qemu-devel@nongnu.org; Thu, 08 Oct 2009 12:07:31 -0400 Date: Thu, 8 Oct 2009 17:07:26 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH v2 3/9] provide in-kernel ioapic Message-ID: <20091008160726.GD29691@shareable.org> References: <1254953315-5761-1-git-send-email-glommer@redhat.com> <1254953315-5761-2-git-send-email-glommer@redhat.com> <1254953315-5761-3-git-send-email-glommer@redhat.com> <1254953315-5761-4-git-send-email-glommer@redhat.com> <4ACDEDEC.60706@us.ibm.com> <4ACDEF03.6010406@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ACDEF03.6010406@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , Glauber Costa , kvm-devel , qemu-devel@nongnu.org Avi Kivity wrote: > On 10/08/2009 03:49 PM, Anthony Liguori wrote: > >Glauber Costa wrote: > >>This patch provides kvm with an in-kernel ioapic. We are currently > >>not enabling it. > >>The code is heavily based on what's in qemu-kvm.git. > > > >It really ought to be it's own file and own device model. Having the > >code mixed in with ioapic.c is confusing because it's unclear what > >code is in use when the in-kernel model is used. > > I disagree. It's the same device with the same guest-visible interface > and the same host-visible interface (save/restore, 'info ioapic' if we > write one). Splitting it into two files will only result in code > duplication. > > Think of it as an ioapic accelerator. Haven't we already confirmed that it *isn't* just an ioapic accelerator because you can't migrate between in-kernel iopic and qemu's ioapic? Imho, if they cannot be swapped transparently, they are different device emulations. OF course there's nothing wrong with sharing lots of code. Maybe ioapic.c and ioapic-kvm.c, with shared code in ioapic-common.c? -- Jamie