From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39425 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OsGUd-0001S9-Ve for qemu-devel@nongnu.org; Sun, 05 Sep 2010 10:46:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OsGUc-00043u-M6 for qemu-devel@nongnu.org; Sun, 05 Sep 2010 10:46:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31937) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OsGUc-00043k-Ak for qemu-devel@nongnu.org; Sun, 05 Sep 2010 10:46:50 -0400 Message-ID: <4C83AD56.2030103@redhat.com> Date: Sun, 05 Sep 2010 17:46:46 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Unmaintained QEMU builds References: <4C62825A.6000903@mail.berlios.de> <4C685F5D.2090707@codemonkey.ws> <4C69A29F.5000606@codemonkey.ws> <4C6AE96C.2040907@codemonkey.ws> <4C837CAF.4080200@redhat.com> <4C83A679.7060907@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , QEMU Developers On 09/05/2010 05:40 PM, Blue Swirl wrote: > On Sun, Sep 5, 2010 at 2:17 PM, Avi Kivity wrote: >> On 09/05/2010 05:10 PM, Blue Swirl wrote: >>> Easy to use GUI and integration to host system are important, but >>> performance is also a big problem. QEMU/TCG can't compete with >>> alternatives that use proprietary kernel modules. Someone should >>> recreate kqemu by using KVM compatible interfaces. >> If someone is really willing to invest the effort to do that cleanly, I am >> willing to merge it into kvm. That would allow reuse of the mmu and some >> other logic that got a lot of effort in kvm. >> >> However, I doubt it is worth the effort, if anyone is interested in >> performance then they'd get a cpu that supports virtualization. >> >> That leaves non-Linux. Can qemu really compete there for x86-on-x86? I >> doubt it. > Someone could also make a KVM compatible module for non-Linux hosts > with virtualization capable CPUs. Someone actually did port kvm-17 or thereabouts to Windows. > Wouldn't that solve most performance > problems? It would. What I doubt is that the qemu community can produce a GUI that rivals with the commercial virtualization GUIs available for Windows. On Linux we have the advantages of being open source and of being integrated with the host native virtualization capabilities. On Windows/Apple the first advantage isn't so important, and the second one doesn't exist. So if qemu were to compete in those markets, it wouldn't have any advantages, but many disadvantages (foremost, being way behind on the GUI front). -- error compiling committee.c: too many arguments to function