From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbRgx-0000su-UK for qemu-devel@nongnu.org; Sun, 21 Aug 2016 08:17:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bbRgt-0000Wr-OR for qemu-devel@nongnu.org; Sun, 21 Aug 2016 08:17:30 -0400 Received: from roura.ac.upc.edu ([147.83.33.10]:58802 helo=roura.ac.upc.es) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbRgt-0000Vu-CT for qemu-devel@nongnu.org; Sun, 21 Aug 2016 08:17:27 -0400 From: =?utf-8?Q?Llu=C3=ADs_Vilanova?= References: <147041636348.2523.2954972609232949598.stgit@fimbulvetr.bsc.es> <20160818094720.GA4850@stefanha-x1.localdomain> <87wpjeqsv9.fsf@fimbulvetr.bsc.es> <20160818135327.GJ4850@stefanha-x1.localdomain> <20160818102156.2c43bc6c@redhat.com> Date: Sun, 21 Aug 2016 14:17:16 +0200 In-Reply-To: <20160818102156.2c43bc6c@redhat.com> (Luiz Capitulino's message of "Thu, 18 Aug 2016 10:21:56 -0400") Message-ID: <87d1l2pb8z.fsf@fimbulvetr.bsc.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/6] hypertrace: Lightweight guest-to-QEMU trace channel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Stefan Hajnoczi , Stefan Hajnoczi , lttng-dev@lists.lttng.org, qemu-devel@nongnu.org, Steven Rostedt , Masami Hiramatsu Luiz Capitulino writes: > On Thu, 18 Aug 2016 14:53:27 +0100 > Stefan Hajnoczi wrote: >> On Thu, Aug 18, 2016 at 12:22:18PM +0200, Llu=C3=ADs Vilanova wrote: >> > Stefan Hajnoczi writes: >> >=20=20=20 >> > > On Fri, Aug 05, 2016 at 06:59:23PM +0200, Llu=C3=ADs Vilanova wrote:= =20=20 >> > >> The hypertrace channel allows guest code to emit events in QEMU (th= e host) using >> > >> its tracing infrastructure (see "docs/trace.txt"). This works in bo= th 'system' >> > >> and 'user' modes. That is, hypertrace is to tracing, what hypercall= s are to >> > >> system calls. >> > >>=20 >> > >> You can use this to emit an event on both guest and QEMU (host) tra= ces to easily >> > >> synchronize or correlate them. You could also modify you guest's tr= acing system >> > >> to emit all events through the hypertrace channel, providing a unif= ied and fully >> > >> synchronized trace log. Another use case is timing the performance = of guest code >> > >> when optimizing TCG (QEMU traces have a timestamp). >> > >>=20 >> > >> See first commit for a full description. >> > >>=20 >> > >> Signed-off-by: Llu=C3=ADs Vilanova >> > >> ---=20=20 >> >=20=20=20 >> > > CCing Steven Rostedt, Masami Hiramatsu, Luiz Capitulino, and LTTng f= olks >> > > who have all looked into host/guest tracing solutions.=20=20 >> > [...] >> >=20 >> > Oh, I wasn't aware of that. I'm certainly interested in collaborating.= =20=20 >>=20 >> They are working on or have worked on different approaches to host/guest >> tracing. Unfortunately there isn't an out-of-the-box solution as far as >> I know. > The ftrace solution is documented here: > https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00887.html > This traces the guest and host kernels. It supports merging the guest > and host traces. It's extremely low latency and has helped us to > find several spikes for real-time KVM (we're talking a few to > a dozen microseconds at most). > Now, our stack actually is: > - Guest app > - Guest kernel > - Host kernel > - QEMU > QEMU already has its own tracing (which I don't know how it works). > If I had to trace the guest app, I'd certainly start off by using > LTTng. Although, we'd have to write a tool to merge and orchestrate > (wooo, cloud buzzword!) all those traces (if that's what one wants). [...] One of my targets was to simplify the merge by providing known reference po= ints between guest and host traces. Cheers, Lluis