From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ingo Molnar <mingo@elte.hu>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project
Date: Thu, 18 Mar 2010 18:16:38 +0100
Message-ID: <20100318171638.GA26067@elte.hu>
References: <20100318085607.GB2157@elte.hu>
 <4BA1FC80.2000401@redhat.com>
 <20100318105013.GB24464@elte.hu>
 <4BA20EB8.60707@redhat.com>
 <20100318114821.GB13168@elte.hu>
 <4BA21B09.6060706@redhat.com>
 <20100318130047.GA7424@elte.hu>
 <4BA22C72.9030503@redhat.com>
 <20100318140933.GE25642@elte.hu>
 <4BA23ADD.4000201@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Sheng Yang <sheng@linux.intel.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	Marcelo Tosatti <mtosatti@redhat.com>,
	oerg Roedel <joro@8bytes.org>,
	Jes Sorensen <Jes.Sorensen@redhat.com>,
	Gleb Natapov <gleb@redhat.com>,
	Zachary Amsden <zamsden@redhat.com>, ziteng.huang@intel.com,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Fr?d?ric Weisbecker <fweisbec@gmail.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <4BA23ADD.4000201@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org


* Avi Kivity <avi@redhat.com> wrote:

> On 03/18/2010 04:09 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi@redhat.com>  wrote:
> >
> >>> That is not what i said. I said they are closely related, and where 
> >>> technologies are closely related, project proximity turns into project 
> >>> unification at a certain stage.
> >>
> >> I really don't see how.  So what if both qemu and kvm implement an i8254? 
> >> They can't share any code since the internal APIs are so different. [...]
> >
> > I wouldnt jump to assumptions there. perf shares some facilities with the 
> > kernel on the source code level - they can be built both in the kernel and 
> > in user-space.
> >
> > But my main thought wasnt even to actually share the implementation - but 
> > to actually synchronize when a piece of device emulation moves into the 
> > kernel. It is arguably bad for performance in most cases when Qemu handles 
> > a given device - so all the common devices should be kernel accelerated.
> >
> > The version and testing matrix would be simplified significantly as well: 
> > as kernel and qemu goes hand in hand, they are always on the same version.
> 
> So, you propose to allow running tools/kvm/ only on the kernel it was 
> shipped with?

No, but i propose concentrating on that natural combination.

> Otherwise the testing matrix isn't simplified.

It is, because testing is more focused and more people are testing the 
combination that developers tested as well. (and not some random version 
combination picked by the distributor or the user)

	Ingo