From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgyeo-0007qV-Eo for qemu-devel@nongnu.org; Mon, 05 Sep 2016 14:30:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgyek-0003n2-84 for qemu-devel@nongnu.org; Mon, 05 Sep 2016 14:30:09 -0400 Received: from roura.ac.upc.es ([147.83.33.10]:36945) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgyej-0003mJ-SM for qemu-devel@nongnu.org; Mon, 05 Sep 2016 14:30:06 -0400 From: =?utf-8?Q?Llu=C3=ADs_Vilanova?= References: <147041636348.2523.2954972609232949598.stgit@fimbulvetr.bsc.es> <20160818105424.GD4850@stefanha-x1.localdomain> <8737lypajh.fsf@fimbulvetr.bsc.es> <20160823155430.GB3948@stefanha-x1.localdomain> <87lgzm4g5p.fsf@fimbulvetr.bsc.es> <20160829134502.GA26282@stefanha-x1.localdomain> <87a8fvjtw5.fsf@fimbulvetr.bsc.es> <20160905145916.GI24656@redhat.com> Date: Mon, 05 Sep 2016 20:29:54 +0200 In-Reply-To: <20160905145916.GI24656@redhat.com> (Daniel P. Berrange's message of "Mon, 5 Sep 2016 15:59:16 +0100") Message-ID: <8760qaryhp.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: "Daniel P. Berrange" Cc: Stefan Hajnoczi , Stefan Hajnoczi , qemu-devel@nongnu.org, Steven Rostedt , Luiz Capitulino , lttng-dev@lists.lttng.org, Masami Hiramatsu Daniel P Berrange writes: > On Mon, Aug 29, 2016 at 08:46:02PM +0200, Llu=C3=ADs Vilanova wrote: >> Stefan Hajnoczi writes: >>=20 >> > When SystemTap is used the QEMU monitor interface does nothing. >>=20 >> That's not what I've experienced. I was able to use a stap script to cha= nge the >> tracing state of events: >>=20 >> #!/usr/bin/env stap >>=20 >> %{ >> #include >> %} >>=20 >> function event:long(cpu:long, addr:long, info:long) >> %{ >> char *argv[4] =3D {"/bin/sh", "-c", "echo 'trace-event * off' | telnet l= ocalhost 1234", NULL}; >> call_usermodehelper(argv[0], argv, NULL, UMH_WAIT_EXEC); >> STAP_RETURN(0); >> %} > I don't know what you're trying to achieve here. The trace-event state, > as changed/viewed via QEMU monitor, is irrelevant to the dtrace (systemta= p) > backend. dtrace and ltt-ust are both fully dynamic trace event backends, > so the QEMU event state has no effect on them. The probe points in the > binary are dynamically enabled / disabled by the dtrace runtime. ie dtrace > will automatically enable an event if you write a dtrace script that uses > the event. Sorry, I did not properly explain the use case. This is an example of using QEMU's tracing infrastructure to control itself. Here I'm using the "log" backend to trace events to disk, and the "dtrace" backend (systemtap) to co= ntrol the tracing state of such events. The guest code is something like: // some guest code executed *without* tracing enabled invoke_hypertrace_event(); // stap will enable some events here // some guest code executed *with* tracing enabled invoke_hypertrace_event(); // stap will disable some events here // some guest code executed *without* tracing enabled So we can use it to mark regions of interest for tracing. Cheers, Lluis