From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StfP0-0000pj-CZ for qemu-devel@nongnu.org; Tue, 24 Jul 2012 09:43:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1StfOq-0003zR-9u for qemu-devel@nongnu.org; Tue, 24 Jul 2012 09:43:54 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:50002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StfOq-0003zE-3d for qemu-devel@nongnu.org; Tue, 24 Jul 2012 09:43:44 -0400 Received: by bkcji1 with SMTP id ji1so5365794bkc.4 for ; Tue, 24 Jul 2012 06:43:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <500E810A.4030309@hitachi.com> References: <20120724023657.6600.52706.stgit@ltc189.sdl.hitachi.co.jp> <500E810A.4030309@hitachi.com> Date: Tue, 24 Jul 2012 14:43:43 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC PATCH 0/6] virtio-trace: Support virtio-trace List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Masami Hiramatsu Cc: Herbert Xu , Arnd Bergmann , Greg Kroah-Hartman , Frederic Weisbecker , Yoshihiro YUNOMAE , Dhaval Giani , linux-kernel@vger.kernel.org, Borislav Petkov , qemu-devel@nongnu.org, "Franch Ch. Eigler" , Ingo Molnar , Mathieu Desnoyers , Steven Rostedt , Anthony Liguori , yrl.pp-manager.tt@hitachi.com, Amit Shah , virtualization@lists.linux-foundation.org, Srikar Dronamraju On Tue, Jul 24, 2012 at 12:03 PM, Masami Hiramatsu wrote: > (2012/07/24 19:02), Stefan Hajnoczi wrote: >> On Tue, Jul 24, 2012 at 3:36 AM, Yoshihiro YUNOMAE >> wrote: >>> The performance of each method is compared as follows: >>> [1] Native >>> - only recording trace data to ring-buffer on a guest >>> [2] Virtio-trace >>> - running a trace agent on a guest >>> - a reader on a host opens FIFO using cat command >>> [3] IVRing >>> - A SystemTap script in a guest records trace data to IVRing. >>> -- probe points are same as ftrace. >>> [4] Virtio-serial(normal) >>> - A reader(using cat) on a guest output trace data to a host using >>> standard output via virtio-serial. >> >> The first time I read this I thought you are adding a new virtio-trace >> device. But it looks like this series really add splice support to >> virtio-console and that yields a big performance improvement when >> sending trace_pipe_raw. > > Yes, sorry for the confusion. Actually this is an enhancement of > virtio-serial. I'm working with Yoshihiro on this feature. > >> Guest ftrace is useful and I like this. Have you thought about >> controlling ftrace from the host? Perhaps a command could be added to >> the QEMU guest agent which basically invokes trace-cmd/perf. > > As you can see, guest trace-agent can be controlled via a > control channel. In our scenario, host tools can control that > instead of guest one. > > We are considering that exporting the tracing part of guest's > debugfs to host via another virtio-serial channel by using > 9pfs, so that the host tools can refer that. > > (In this scenario, guest trace-agent will also provide 9pfs server. > Since it means that the agent can handle writing a special file, > trace-agent can be controlled via the special file on exported > debugfs.) > > Of course, this also requires modifying trace-cmd/perf to accept > some options like guest-debugfs mount point, guest's serial > channel pipe (or unix socket?), etc. However, it will be a small > change. Okay, thanks for explaining some of the ideas you have. I won't ask more because it's out of scope for this patch series :). Stefan