From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side Date: Tue, 16 Mar 2010 14:41:14 +0200 Message-ID: <4B9F7C6A.3070207@redhat.com> References: <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> <4B9F77E7.2060101@redhat.com> <20100316122903.GA8831@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 To: Ingo Molnar Return-path: In-Reply-To: <20100316122903.GA8831@elte.hu> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 03/16/2010 02:29 PM, Ingo Molnar wrote: > * Avi Kivity wrote: > > >> 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. >> > How do i get a list of all 'guest instance PIDs', Libvirt manages all qemus, but this should be implemented independently of libvirt. > and what is the way to talk > to Qemu? > In general qemu exposes communication channels (such as the monitor) as tcp connections, unix-domain sockets, stdio, etc. It's very flexible. >>> Can we trust it? >>> >> No choice, it contains the guest address space. >> > I mean, i can trust a kernel service and i can trust /proc/kallsyms. > > Can perf trust a random process claiming to be Qemu? What's the trust > mechanism here? > Obviously you can't trust anything you get from a guest, no matter how you get it. How do you trust a userspace program's symbols? you don't. How do you get them? they're on a well-known location. >>> 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. >> > So Qemu has never run into such problems before? > > ( Sounds weird - i think Qemu configuration itself should be done via a > unix domain socket driven configuration protocol as well. ) > That's exactly what happens. You invoke qemu with -monitor unix:blah,server (or -qmp for a machine-readable format) and have your management application connect to that. You can redirect guest serial ports, console, parallel port, etc. to unix-domain or tcp sockets. vmchannel is an extension of that mechanism. >>> ( 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/. >> > Certainly not, but this is a technical problem in the kernel's domain, so it's > a fair (and natural) expectation to be able to solve this within the kernel > project. > Someone writing perf-gui outside the kernel would have the same problems, no? -- error compiling committee.c: too many arguments to function