From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beRZe-0000ry-9z for qemu-devel@nongnu.org; Mon, 29 Aug 2016 14:46:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beRZa-0001iS-2I for qemu-devel@nongnu.org; Mon, 29 Aug 2016 14:46:21 -0400 Received: from roura.ac.upc.edu ([147.83.33.10]:43718 helo=roura.ac.upc.es) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beRZZ-0001iN-Mv for qemu-devel@nongnu.org; Mon, 29 Aug 2016 14:46:17 -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> Date: Mon, 29 Aug 2016 20:46:02 +0200 In-Reply-To: <20160829134502.GA26282@stefanha-x1.localdomain> (Stefan Hajnoczi's message of "Mon, 29 Aug 2016 09:45:02 -0400") Message-ID: <87a8fvjtw5.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: Stefan Hajnoczi , qemu-devel@nongnu.org, Steven Rostedt , Luiz Capitulino , lttng-dev@lists.lttng.org, Masami Hiramatsu Stefan Hajnoczi writes: > On Wed, Aug 24, 2016 at 12:25:54PM +0200, Llu=C3=ADs Vilanova wrote: >> Stefan Hajnoczi writes: >>=20 >> > On Sun, Aug 21, 2016 at 02:32:34PM +0200, Llu=C3=ADs Vilanova wrote: >> >> Unfortuntely, I've been unable to to make dtrace recognise QEMU's eve= nts (I'm >> >> only able to see the host kernel events). If someone with more experi= ence on it >> >> can help me use dtrace with QEMU's events, I'll also add the supporti= ng library >> >> to let dtrace do the callout to QEMU's moitor interface and control t= he events, >> >> and add a prperly useful example of that on the hypertrace docs (whic= h was my >> >> original intention). >>=20 >> > Which "dtrace" and host OS are you using? >>=20 >> > QEMU builds with static user-space probes. You need to tell DTrace or >> > SystemTap to enable those probes in order to record trace data. >>=20 >> I'm using debian on a 4.6.0-1-amd64 kernel with systemtap 3.0.6. >>=20 >> I just gave it another try, and works if I use probes like: >>=20 >> process("").mark("") >>=20 >> although they don't seem to appear on "stap -l" or anything like that (I= cannot >> find a "qemu" provider). But I'm still unable to print the event values.= This: > The following enumerates events for me: > $ sudo stap -L 'process("/usr/bin/qemu-system-x86_64").mark("*")' > process("/usr/bin/qemu-system-x86_64").mark("alsa_no_frames") $arg1:long > process("/usr/bin/qemu-system-x86_64").mark("alsa_pollout") $arg1:long $a= rg2:long > process("/usr/bin/qemu-system-x86_64").mark("alsa_read_zero") $arg1:long > ... > You can also use /usr/share/systemtap/tapset/qemu-system-x86_64.stp. > I'm running Fedora 24 with qemu-system-x86 2.6.0-5.fc24 and SystemTap > 3.0-3.fc24. I meant I cannot just use "qemu" as a provider name. Later I discovered that "process()" does work. >> Also, I'm still not sure how to interact with QEMU's monitor interface f= rom >> within the probe code (probes execute in kernel mode, including "guru mo= de" >> code). > When SystemTap is used the QEMU monitor interface does nothing. That's not what I've experienced. I was able to use a stap script to change= the tracing state of events: #!/usr/bin/env stap %{ #include %} 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); %} probe begin { printf("hello\n") } probe process("./install/vanilla/bin/qemu-system-i386").mark("guest_mem_= before_exec") { printf("%x %d %d\n", $arg1, $arg2, $arg3) event($arg1, $arg2, $arg3) exit() } The only caveat is that you must pass the "-g" argument to stap. Also, for some reason the printf in the probe always prints zeros, no matter what the actual event receives (I've debugged QEMU down to the call to the auto-generated stap functions). Could this be an error in systemtap? Thanks, Lluis