From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvuB7-0004eS-C8 for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:41:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvuB2-0004bV-Um for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:41:13 -0400 Received: from [199.232.76.173] (port=48461 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvuB2-0004bO-IB for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:41:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2161) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MvuB2-0002QL-22 for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:41:08 -0400 Message-ID: <4ACDF9FD.8060704@redhat.com> Date: Thu, 08 Oct 2009 16:41:01 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2 9/9] Add -kvm option 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> <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> <4ACDF82B.4010200@codemonkey.ws> In-Reply-To: <4ACDF82B.4010200@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Mark McLoughlin , Anthony Liguori , Gerd Hoffmann , Glauber Costa , qemu-devel@nongnu.org On 10/08/2009 04:33 PM, Anthony Liguori wrote: > 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. > > That's not always been true historically. For instance, the in-kernel > pit does interrupt catchup whereas the userspace pit does not. That's a bug in the userspace pit :) I'm worried about things like 'info pit' needing dual implementations. >> We'll have the same problem with vhost-net, only there the >> duplication will be much greater if we split the implementation. > > I'd rather not treat vhost-net like a device model and instead treat > it like a -net backend. If we can bounce requests through userspace > (and we can), we should be able to use it for any device model. In > the case of virtio-net, we should be able to short-circuit things such > that we don't have to go through userspace. It's admittedly very > hairy without a point-to-point net abstraction. > Interesting idea. I think it'll be hairy even with a point-to-point net abstraction, but it's worth trying. -- error compiling committee.c: too many arguments to function