From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single project Date: Mon, 22 Mar 2010 20:22:59 +0100 Message-ID: <20100322192259.GD21919@elte.hu> References: <20100322124428.GA12475@elte.hu> <4BA76810.4040609@redhat.com> <20100322143212.GE14201@elte.hu> <4BA7821C.7090900@codemonkey.ws> <20100322155505.GA18796@elte.hu> <4BA796DF.7090005@redhat.com> <20100322165107.GD18796@elte.hu> <4BA7A406.9050203@redhat.com> <20100322173400.GB15795@elte.hu> <4BA7B87A.8060104@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Pekka Enberg , "Zhang, Yanmin" , Peter Zijlstra , Sheng Yang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Marcelo Tosatti , oerg Roedel , Jes Sorensen , Gleb Natapov , Zachary Amsden , ziteng.huang@intel.com, Arnaldo Carvalho de Melo , Fr?d?ric Weisbecker , Gregory Haskins To: Anthony Liguori Return-path: Content-Disposition: inline In-Reply-To: <4BA7B87A.8060104@codemonkey.ws> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org * Anthony Liguori wrote: > On 03/22/2010 12:34 PM, Ingo Molnar wrote: > >* Avi Kivity wrote: > > > >>>>> - Easy default reference to guest instances, and a way for tools to > >>>>> reference them symbolically as well in the multi-guest case. Preferably > >>>>> something trustable and kernel-provided - not some indirect information > >>>>> like a PID file created by libvirt-manager or so. > >>>>Usually 'layering violation' is trotted out at such suggestions. > >>>>[...] > >>>That's weird, how can a feature request be a 'layering violation'? > >>The 'something trustable and kernel-provided'. The kernel knows nothing > >>about guest names. > >The kernel certainly knows about other resources such as task names or network > >interface names or tracepoint names. This is kernel design 101. > > > >>>If something that users find straightforward and usable is a layering > >>>violation to you (such as easily being able to access their own files on > >>>the host as well ...) then i think you need to revisit the definition of > >>>that term instead of trying to fix the user. > >>Here is the explanation, you left it quoted: > >> > >>>>[...] I don't like using the term, because sometimes the layers are > >>>>incorrect and need to be violated. But it should be done explicitly, not > >>>>as a shortcut for a minor feature (and profiling is a minor feature, most > >>>>users will never use it, especially guest-from-host). > >>>> > >>>>The fact is we have well defined layers today, kvm virtualizes the cpu > >>>>and memory, qemu emulates devices for a single guest, libvirt manages > >>>>guests. We break this sometimes but there has to be a good reason. So > >>>>perf needs to talk to libvirt if it wants names. Could be done via > >>>>linking, or can be done using a pluging libvirt drops into perf. > >This is really just the much-discredited microkernel approach for keeping > >global enumeration data that should be kept by the kernel ... > > > >Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by Anthony. > >There's numerous ways that this can break: > > > > - Those special files can get corrupted, mis-setup, get out of sync, or can > > be hard to discover. > > > > - The ${HOME}/.qemu/qmp/ solution suggested by Anthony has a very obvious > > design flaw: it is per user. When i'm root i'd like to query _all_ current > > guest images, not just the ones started by root. A system might not even > > have a notion of '${HOME}'. > > > > - Apps might start KVM vcpu instances without adhering to the > > ${HOME}/.qemu/qmp/ access method. > > Not all KVM vcpus are running operating systems. But we want to allow developers to instrument all of them ... > Transitive had a product that was using a KVM context to run their > binary translator which allowed them full access to the host > processes virtual address space range. In this case, there is no > kernel and there are no devices. And your point is that such vcpus should be excluded from profiling just because they fall outside the Qemu/libvirt umbrella? That is a ridiculous position. Ingo