From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM usability Date: Sun, 07 Mar 2010 20:25:17 +0200 Message-ID: <4B93EF8D.60408@redhat.com> References: <1267089644.12790.74.camel@laptop> <1267152599.1726.76.camel@localhost> <20100226090147.GH15885@elte.hu> <4B879A2F.50203@redhat.com> <20100226103545.GA7463@elte.hu> <4B87A6BF.3090301@redhat.com> <20100226111734.GE7463@elte.hu> <4B8813F2.8090208@redhat.com> <20100227105643.GA17425@elte.hu> <4B893B2B.40301@redhat.com> <20100227172546.GA31472@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Zachary Amsden , Anthony Liguori , "Zhang, Yanmin" , Peter Zijlstra , ming.m.lin@intel.com, sheng.yang@intel.com, Jes Sorensen , KVM General , Gleb Natapov , Arnaldo Carvalho de Melo , Fr??d??ric Weisbecker , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Arjan van de Ven To: Ingo Molnar Return-path: Received: from mx1.redhat.com ([209.132.183.28]:32314 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753165Ab0CGS12 (ORCPT ); Sun, 7 Mar 2010 13:27:28 -0500 In-Reply-To: <20100227172546.GA31472@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/27/2010 07:25 PM, Ingo Molnar wrote: > * Zachary Amsden wrote: > > [...] > >> Second, it's not over-modularized. The modules are the individual >> components of the architecture. How would you propose to put it >> differently. They really can't naturally combine. And with the >> code quality of qemu in general being problematic by Linux kernel >> standards, it's not natural to move the device emulation directly >> into the kernel module. So this is why we are where we are today. >> > I'm not talking about moving it into a kernel _module_ - albeit that > alone is a worthwile thing to do for any performance sensitive hw > component. > Moving qemu into the kernel is preposterous. It's a huge code base (even a stripped down version) with many external dependencies. You're converting a guest crash into a host crash, and a simple binary update into a reboot. What makes sense is identifying the performance critical bits and creating generally useful kernel interfaces that can be used to speed them up, or kvm-specific kernel accelerations. Example include preadv/pwritev (generic) and vhost-net (specific). > I was talking about the option of a clean, stripped down Qemu base > hosted in the kernel proper, in linux/tools/kvm/ or so. If i were > running a virtualization effort it would be the first place i'd > consider to put my tooling into. > > It would be a no-brainer: most of the devs come from the KVM side, and > KVM itself makes little sense without Qemu, and Qemu makes little sense > without KVM these days. (and i know about the non-KVM and non-x86 > roots of Qemu - still, it's not a significant piece of usage today) > It's true that qemu development is dominated these days by kvm development. If the qemu community was dysfunctional (as it once was) then it makes sense to fork it. But it isn't, so it doesn't. Note also that kvm is not x86 only. >> Third, it's the maintainers upstream who are in charge of KVM >> quality as a whole - when you are talking about upstream code >> quality, and the package maintainers who are in charge of KVM >> quality as a whole - when you are talking about a distro. This is >> nothing new - it's just a statement of decentralization. >> > It's certainly nothing new. Nor was the suckage of CVS newup until > Git came along and changed the game on a fundamental basis. > Bitkeeper deserves some credit here. > Suckage is there to be fought all the time. > Send patches, not flames. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.