From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937844Ab0CPMWR (ORCPT ); Tue, 16 Mar 2010 08:22:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58105 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937726Ab0CPMWQ (ORCPT ); Tue, 16 Mar 2010 08:22:16 -0400 Message-ID: <4B9F77E7.2060101@redhat.com> Date: Tue, 16 Mar 2010 14:21:59 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 MIME-Version: 1.0 To: Ingo Molnar CC: "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 Subject: Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side References: <1268717232.2813.36.camel@localhost> <4B9F19F7.6000309@redhat.com> <20100316072449.GB11881@elte.hu> <4B9F4D74.4090403@redhat.com> <20100316095336.GI7961@elte.hu> <4B9F59DE.1060008@redhat.com> <20100316102052.GC10069@elte.hu> <4B9F603B.4080004@redhat.com> <20100316105021.GA14344@elte.hu> <4B9F671D.5060001@redhat.com> <20100316112500.GA5337@elte.hu> In-Reply-To: <20100316112500.GA5337@elte.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/16/2010 01:25 PM, Ingo Molnar wrote: > >> I haven't followed vmchannel closely, but I think it is. vmchannel is >> terminated in qemu on the host side, not in the host kernel. So perf would >> need to connect to qemu. >> > Hm, that sounds rather messy if we want to use it to basically expose kernel > functionality in a guest/host unified way. Is the qemu process discoverable in > some secure way? We know its pid. > Can we trust it? No choice, it contains the guest address space. > Is there some proper tooling available to do > it, or do we have to push it through 2-3 packages to get such a useful feature > done? > libvirt manages qemu processes, but I don't think this should go through libvirt. qemu can do this directly by opening a unix domain socket in a well-known place. > ( That is the general thought process how many cross-discipline useful > desktop/server features hit the bit bucket before having had any chance of > being vetted by users, and why Linux sucks so much when it comes to feature > integration and application usability. ) > You can't solve everything in the kernel, even with a well populated tools/. -- error compiling committee.c: too many arguments to function