From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj0r0-0004Zl-Ey for qemu-devel@nongnu.org; Thu, 24 Mar 2016 04:42:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj0qv-0004Wk-BL for qemu-devel@nongnu.org; Thu, 24 Mar 2016 04:42:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj0qv-0004Wg-6K for qemu-devel@nongnu.org; Thu, 24 Mar 2016 04:42:49 -0400 Date: Thu, 24 Mar 2016 16:42:42 +0800 From: Peter Xu Message-ID: <20160324084242.GD28183@pxdev.xzpeter.org> References: <20160303143501.0edf21a2@redhat.com> <20160304111933.GB626@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160304111933.GB626@stefanha-x1.localdomain> Subject: Re: [Qemu-devel] [RFC] host and guest kernel trace merging List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kvm@vger.kernel.org, yoshihiro.yunomae.ez@hitachi.com, mtosatti@redhat.com, qemu-devel@nongnu.org, rostedt@goodmis.org, Luiz Capitulino , linux-trace-users@vger.kernel.org, stefanha@redhat.com, pbonzini@redhat.com On Fri, Mar 04, 2016 at 11:19:33AM +0000, Stefan Hajnoczi wrote: > On Thu, Mar 03, 2016 at 02:35:01PM -0500, Luiz Capitulino wrote: > > trace-cmd-server > > ================ > > > > Everything I described could look like this: > > > > # trace-cmd server [ in the host ] > > # trace-cmd record [ in the guest ] > > # trace-cmd report [ in the host, to merge the traces ] > > > > To achieve this, we need two things: > > > > 1. Add an interface to obtain the guest TSC offset from the > > host user-space. > > > > Maybe we could have a new sysfs directory, with a file > > per vCPU thread and the offset as contents? Or maybe > > just add a new entry to /proc/, like: /proc/TID/tsc-offset? > > Yes, the interface is missing. In the past I have heard people using > trace events on the host to: > > 1. Collect tsc offsets > 2. Track which vCPU is scheduled to a host CPU > > So instead of relying on an interface they enable the relevant trace > events on the host and then parse the trace to collect this information. > However, it's a bad solution especially for tsc offsets since you may > wish to trace an already-running VM where the tracepoint that records > the tsc offset may not fire after startup (?). > > Therefore, I agree that an interface for the tsc offset is needed. It seems that KVM still has no such a generic interface to query VM status, right? How about we create one for it? As a start, we can make it fairly simple. Afterward, we can enrich it when necessary. For example: we create this directory to store all KVM guest informations (or general KVM dynamic informations): /sys/hypervisor/kvm/ For each VM, we can have this to store VM specific infos: /sys/hypervisor/kvm/$VM_NAME For each vCPU: /sys/hypervisor/kvm/$VM_NAME/cpus/cpuN/ and we can put tsc-offset here like: /sys/hypervisor/kvm/$VM_NAME/cpus/cpuN/tsc-offset Would this be workable? Thanks. -- peterx