From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbRvq-0006B0-NZ for qemu-devel@nongnu.org; Sun, 21 Aug 2016 08:32:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bbRvk-0002uk-OB for qemu-devel@nongnu.org; Sun, 21 Aug 2016 08:32:53 -0400 Received: from roura.ac.upc.edu ([147.83.33.10]:45876 helo=roura.ac.upc.es) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbRvk-0002uX-CO for qemu-devel@nongnu.org; Sun, 21 Aug 2016 08:32:48 -0400 From: =?utf-8?Q?Llu=C3=ADs_Vilanova?= References: <147041636348.2523.2954972609232949598.stgit@fimbulvetr.bsc.es> <20160818105424.GD4850@stefanha-x1.localdomain> Date: Sun, 21 Aug 2016 14:32:34 +0200 In-Reply-To: <20160818105424.GD4850@stefanha-x1.localdomain> (Stefan Hajnoczi's message of "Thu, 18 Aug 2016 11:54:24 +0100") Message-ID: <8737lypajh.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: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, Steven Rostedt , Luiz Capitulino , lttng-dev@lists.lttng.org, Masami Hiramatsu , Stefan Hajnoczi Stefan Hajnoczi writes: > On Fri, Aug 05, 2016 at 06:59:23PM +0200, Llu=C3=ADs Vilanova wrote: >> The hypertrace channel allows guest code to emit events in QEMU (the hos= t) using >> its tracing infrastructure (see "docs/trace.txt"). This works in both 's= ystem' >> and 'user' modes. That is, hypertrace is to tracing, what hypercalls are= to >> system calls. >>=20 >> You can use this to emit an event on both guest and QEMU (host) traces t= o easily >> synchronize or correlate them. You could also modify you guest's tracing= system >> to emit all events through the hypertrace channel, providing a unified a= nd fully >> synchronized trace log. Another use case is timing the performance of gu= est code >> when optimizing TCG (QEMU traces have a timestamp). >>=20 >> See first commit for a full description. > This tracing approach has a high performance overhead, particularly for > SMP guests where each trace event requires writing to the global control > register. All CPUs will be hammering this register (heavyweight vmexit) > for each trace event. > I think the folks CCed on this email all take an asynchronous approach > to avoid this performance overhead. Synchronous means taking a VM exit > for every event. Asynchronous means writing trace data to a buffer and > later interleaving guest data with host trace data. > LTTng Userspace Tracer is an example of the asynchronous approach. The > trace data buffers are in shared memory. The LTTng process can grab > buffers at appropriate times. > The ftrace virtio-serial approach has been to splice() the ftrace > buffers, resulting in efficient I/O. > Steven is working on a host/guest solution for trace-cmd. It is also > asynchronous. No new paravirt hardware is needed and it makes me wonder > whether the hypertrace PCI device is trying to solve the problem at the > wrong layer. > If you want to play around with asynchronous tracing, you could start > with trace/simple.c. It has a trace buffer that is asynchronously > written out to file by a dedicated "writer" thread. > The one case where hypertrace makes sense to me is for -user tracing. > There QEMU can efficiently interleave guest and QEMU traces, although as > mentioned in the patch, I don't think the SIGSEGV approach should be > used. > I suggest stripping this series down to focus on -user. Synchronous > tracing is not a good approach for -system emulation. As I said, I wanted to implement a simple way to provide common reference p= oints in guest and host traces. For that, a *synchronous* guest-to-host channel i= s the simplest way to do it (otherwise you're back to square one). Another reason to have this is that I wanted to attach a dtrace/systemtap h= ook to the hypertrace event, and from there dynamically control QEMU's tracing.= Then you can insert simple calls to hypertrace on your guest code to tell your d= trace hooks when to enable/disable tracing of certain QEMU events (like guest ins= tr traces). Unfortuntely, I've been unable to to make dtrace recognise QEMU's events (I= 'm only able to see the host kernel events). If someone with more experience o= n it can help me use dtrace with QEMU's events, I'll also add the supporting lib= rary to let dtrace do the callout to QEMU's moitor interface and control the eve= nts, and add a prperly useful example of that on the hypertrace docs (which was = my original intention). Thanks, Lluis