From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mvu5D-0002DD-24 for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:35:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mvu58-0002Ap-5z for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:35:06 -0400 Received: from [199.232.76.173] (port=44336 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mvu57-0002Ah-W0 for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:35:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57115) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mvu56-0001Er-SO for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:35:01 -0400 Date: Thu, 8 Oct 2009 16:34:54 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [PATCH v2 9/9] Add -kvm option Message-ID: <20091008143454.GH16702@redhat.com> References: <1254953315-5761-5-git-send-email-glommer@redhat.com> <1254953315-5761-6-git-send-email-glommer@redhat.com> <1254953315-5761-7-git-send-email-glommer@redhat.com> <1254953315-5761-8-git-send-email-glommer@redhat.com> <1254953315-5761-9-git-send-email-glommer@redhat.com> <1254953315-5761-10-git-send-email-glommer@redhat.com> <4ACD1D92.8080607@us.ibm.com> <4ACDF233.3090500@redhat.com> <4ACDF5D2.2070408@codemonkey.ws> <4ACDF779.2040505@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ACDF779.2040505@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Andre Przywara , Anthony Liguori , Glauber Costa , qemu-devel@nongnu.org, Gerd Hoffmann On Thu, Oct 08, 2009 at 04:30:17PM +0200, Avi Kivity wrote: > On 10/08/2009 04:23 PM, Anthony Liguori wrote: > >>>What I'd like to see in the interim is a kvm specific machine > >>>type that's defaulted to if kvm is enabled. I think this > >>>would be useful not only for enabling things like in-kernel > >>>apic, but also for selecting a default cpu model. > >> > >>We should make a distinction between guest-visible changes and > >>accelerators like kvm-irqchip and vhost. > > > >They are different device models that happen to implement the same > >guest-visible device. > > I think this separation is artificial. From both the guest's view > and the user's view, there's no difference between qemu ioapic and > kvm ioapic (modulo bugs). To me this indicates they're the same > device. > Same device but different implementation. The only two things that are used from qemu apic implementation with in-kernel apic are migration and reset. Both depends on implementation. Reusing code will require us to keep implementation in sync. This reuse is a constant source of bugs BTW. > We'll have the same problem with vhost-net, only there the > duplication will be much greater if we split the implementation. > > -- > error compiling committee.c: too many arguments to function > > -- Gleb.