From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgz7M-0007tB-Ns for qemu-devel@nongnu.org; Mon, 05 Sep 2016 14:59:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgz7J-0000Wo-1J for qemu-devel@nongnu.org; Mon, 05 Sep 2016 14:59:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgz7I-0000W5-Pz for qemu-devel@nongnu.org; Mon, 05 Sep 2016 14:59:36 -0400 Date: Mon, 5 Sep 2016 19:59:30 +0100 From: "Daniel P. Berrange" Message-ID: <20160905185930.GP24656@redhat.com> Reply-To: "Daniel P. Berrange" 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8760qaryhp.fsf@fimbulvetr.bsc.es> 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 , Stefan Hajnoczi , qemu-devel@nongnu.org, Steven Rostedt , Luiz Capitulino , lttng-dev@lists.lttng.org, Masami Hiramatsu 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' | teln= et 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 sta= te, > > as changed/viewed via QEMU monitor, is irrelevant to the dtrace (syst= emtap) > > backend. dtrace and ltt-ust are both fully dynamic trace event backen= ds, > > so the QEMU event state has no effect on them. The probe points in th= e > > binary are dynamically enabled / disabled by the dtrace runtime. ie d= trace > > will automatically enable an event if you write a dtrace script that = uses > > the event. >=20 > Sorry, I did not properly explain the use case. This is an example of u= sing > QEMU's tracing infrastructure to control itself. Here I'm using the "lo= g" > backend to trace events to disk, and the "dtrace" backend (systemtap) t= o control > the tracing state of such events. Ah, I see. I guess I'd personally just have systemtap/dtrace directly emi= t the data to be recorded, and avoid the log backend entirely. Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|