From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: KVM usability Date: Mon, 01 Mar 2010 06:48:07 -1000 Message-ID: <4B8BEFC7.2040000@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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , 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]:5915 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751269Ab0CAQs7 (ORCPT ); Mon, 1 Mar 2010 11:48:59 -0500 In-Reply-To: <20100227172546.GA31472@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/27/2010 07:25 AM, 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. > > 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. > The problem is there is no way to clean and strip down the Qemu code. It's got nicely abstracted bus and device interfaces, for example, but then these go poking under the covers at things which require interacting with the display rendering library or remoting interface, which is not something to reasonably do in the kernel. So ripping out a clean part interface like PCI bus infrastructure and using it in the kernel, for example, does nothing except put that infrastructure in two different places, because everything the kernel does, userspace will have to do again anyway. So now you have twice as much code involving the same idea and you have to keep the pieces in sync and from trampling each other. The only parts that warrant such complexity and high risk for bugs are performance critical things like the PIT and APIC. Zach