From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Enhance perf to support KVM Date: Fri, 26 Feb 2010 16:04:43 +0200 Message-ID: <4B87D4FB.2060200@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> <4B87B407.2070309@redhat.com> <20100226124646.GB19476@elte.hu> <4B87C494.4090306@redhat.com> <20100226131614.GB2518@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Zhang, Yanmin" , Peter Zijlstra , ming.m.lin@intel.com, sheng.yang@intel.com, Jes Sorensen , KVM General , Zachary Amsden , 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]:19535 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936288Ab0BZOFZ (ORCPT ); Fri, 26 Feb 2010 09:05:25 -0500 In-Reply-To: <20100226131614.GB2518@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 03:16 PM, Ingo Molnar wrote: > * Avi Kivity wrote: > > >>> That was not what i suggested tho. tools/kvm/ would work plenty fine. >>> >> I'll wait until we have tools/libc and tools/X. After all, they affect a >> lot more people and are concerned with a lot more kernel/user interfaces >> than kvm. >> > So your answer can be summed up as: 'we wont do what makes sense technically > because others suck even more' ? > I can sum up your this remark as 'whenever you disagree with me, I will rephrase your words to make you look like an idiot'. If you believe I'm an idiot, there's no need to have this (or any) conversation. If not, please refrain from this type of verbal gymnastics. > And it's not just the kernel<->user interface (which btw., for the case of X > is far narrower than what KVM currently has to Qemu). > > The issue is a basic question of software design: does kvm-qemu really make as > much sense without the kernel component as with it? The answer is: it will > borderline-work with CPU emulation (and i'm sure there are people making use > of it that way), but 90%+ of the userbase uses it with KVM and vice versa. It > is really a single logical component as far as maintenance goes, and > tools/kvm/ would make quite a bit of sense. > There are two separate questions. Is there room for a kvm-only userspace component? I believe so, but throwing away the momentum behind qemu would be foolish. Does it make sense for such a component to live in linux.git? IMO, no, and certainly a lot less than libc and X. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.