From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhC9p-0000c8-N9 for qemu-devel@nongnu.org; Tue, 06 Sep 2016 04:55:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhC9i-0006Y7-PP for qemu-devel@nongnu.org; Tue, 06 Sep 2016 04:55:04 -0400 Received: from roura.ac.upc.edu ([147.83.33.10]:51839 helo=roura.ac.upc.es) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhC9i-0006Xx-Dt for qemu-devel@nongnu.org; Tue, 06 Sep 2016 04:54:58 -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> <8760qaryhp.fsf@fimbulvetr.bsc.es> <20160905185930.GP24656@redhat.com> Date: Tue, 06 Sep 2016 10:54:46 +0200 In-Reply-To: <20160905185930.GP24656@redhat.com> (Daniel P. Berrange's message of "Mon, 5 Sep 2016 19:59:30 +0100") Message-ID: <8737ldpfvt.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, Sep 05, 2016 at 08:29:54PM +0200, Llu=C3=ADs Vilanova wrote: >> Daniel P Berrange writes: >>=20 >> > 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 = change 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' | telne= t localhost 1234", NULL}; >> >> call_usermodehelper(argv[0], argv, NULL, UMH_WAIT_EXEC); >> >> STAP_RETURN(0); >> >> %} >>=20 >> > I don't know what you're trying to achieve here. The trace-event stat= e, >> > as changed/viewed via QEMU monitor, is irrelevant to the dtrace (syste= mtap) >> > backend. dtrace and ltt-ust are both fully dynamic trace event backend= s, >> > 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 dt= race >> > will automatically enable an event if you write a dtrace script that u= ses >> > the event. >>=20 >> Sorry, I did not properly explain the use case. This is an example of us= ing >> 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= control >> the tracing state of such events. > Ah, I see. I guess I'd personally just have systemtap/dtrace directly emit > the data to be recorded, and avoid the log backend entirely. Backends with a buffered output stream like "simple" should be faster than "dtrace", which AFAIK injects a software trap. Also, you can take advantage= of existing QEMU infrastructure to control the tracing of events, instead of implementing your own on each script. Cheers, Lluis