From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project
Date: Mon, 22 Mar 2010 08:37:06 +0200
Message-ID: <4BA71012.7070004@redhat.com>
References: <20100318170223.GB9756@elte.hu> <4BA25E66.2050800@redhat.com> <20100318172805.GB26067@elte.hu> <4BA32E1A.2060703@redhat.com> <20100319085346.GG12576@elte.hu> <4BA3747F.60401@codemonkey.ws> <20100321191742.GD25922@elte.hu> <4BA67B2F.4030101@redhat.com> <20100321200849.GA51323@dspnet.fr.eu.org> <4BA67D75.8060809@redhat.com> <20100321203704.GB30194@elte.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Olivier Galibert <galibert@pobox.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	"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: Ingo Molnar <mingo@elte.hu>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20100321203704.GB30194@elte.hu>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

On 03/21/2010 10:37 PM, Ingo Molnar wrote:
>
>> That includes the guest kernel.  If you can deploy a new kernel in the
>> guest, presumably you can deploy a userspace package.
>>      
> Note that with perf we can instrument the guest with zero guest-kernel
> modifications as well.
>
> We try to reduce the guest impact to a bare minimum, as the difficulties in
> deployment are function of the cross section surface to the guest.
>
> Also, note that the kernel is special with regards to instrumentation: since
> this is the kernel project, we are doing kernel space changes, as we are doing
> them _anyway_. So adding symbol resolution capabilities would be a minimal
> addition to that - while adding a while new guest package for the demon would
> significantly increase the cross section surface.
>    

It's true that for us, changing the kernel is easier than changing the 
rest of the guest.  IMO we should still resist the temptation to go the 
easy path and do the right thing (I understand we disagree about what 
the right thing is).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.