From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhFyx-00060a-B0 for qemu-devel@nongnu.org; Tue, 06 Sep 2016 09:00:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhFys-0007pg-6G for qemu-devel@nongnu.org; Tue, 06 Sep 2016 09:00:06 -0400 Received: from roura.ac.upc.es ([147.83.33.10]:57692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhFyr-0007oi-Qd for qemu-devel@nongnu.org; Tue, 06 Sep 2016 09:00:02 -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> <20160831163547.GD18281@stefanha-x1.localdomain> <87y436mn02.fsf@fimbulvetr.bsc.es> <20160906042018.dd1e1dc6df8de1e1ebb38a50@kernel.org> Date: Tue, 06 Sep 2016 14:59:49 +0200 In-Reply-To: <20160906042018.dd1e1dc6df8de1e1ebb38a50@kernel.org> (Masami Hiramatsu's message of "Tue, 6 Sep 2016 04:20:18 +0900") Message-ID: <87mvjl89q2.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: Masami Hiramatsu Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, Steven Rostedt , Luiz Capitulino , lttng-dev@lists.lttng.org, Stefan Hajnoczi Masami Hiramatsu writes: > On Mon, 05 Sep 2016 16:37:01 +0200 > Llu=C3=ADs Vilanova wrote: >> Stefan Hajnoczi writes: >>=20 >> > On Mon, Aug 29, 2016 at 08:46:02PM +0200, Llu=C3=ADs Vilanova wrote: >> >> >> Also, I'm still not sure how to interact with QEMU's monitor inter= face from >> >> >> within the probe code (probes execute in kernel mode, including "g= uru mode" >> >> >> code). >> >>=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 >> >> probe begin { >> >> printf("hello\n") >> >> } >> >> probe process("./install/vanilla/bin/qemu-system-i386").mark("guest_m= em_before_exec") >> >> { >> >> printf("%x %d %d\n", $arg1, $arg2, $arg3) >> >> event($arg1, $arg2, $arg3) >> >> exit() >> >> } >> >>=20 >> >> The only caveat is that you must pass the "-g" argument to stap. >> >>=20 >> >> 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 t= o the >> >> auto-generated stap functions). Could this be an error in systemtap? >>=20 >> > It's strange that arguments do not have valid values. Debugging the >> > stap functions is the next step if you want to figure out what happene= d. >> > I've never had this issue before so maybe something with Debian >> > SystemTap userspace probes is broken. >>=20 >> I already debugged it, to the point where QEMU executes the trap injecte= d by >> systemtap, and the register values that were supposed to hold the argume= nts are >> correct. >>=20 >> I suppose that if you execute the stap script I pasted it will show the = proper >> values. Then it's definitely a problem with Debian's userspace probes. > Would you have tried to update your kernel to mainline and tested it ? I've compiled the tarball for 4.8-rc5 (.config from "make localmodconfig") = and a printf of the probe arguments still shows zeroes. Also, I've had to add a s= mall patch to [1] to properly lock/unlock inodes in this kernel version (using inode_lock/unlock instead of mutex_lock/unlock on inode->i_mutex). [1] /usr/share/systemtap/runtime/transport/transport.c > If it occurs, you also should try to use a raw uprobe via ftrace(uprobe_e= vents) > and perftools. > If you have the latest perf (maybe you'll need checkout the latest tip tr= ee), > you can use SDT as below (currently it doesn't support args, so you'll ne= ed > debuginfo.) > # perf buildid-cache --add ./install/vanilla/bin/qemu-system-i386 > # perf probe -x ./install/vanilla/bin/qemu-system-i386 -a 'guest_mem_befo= re_exec $vars' > And you'll see new event is registered which can be traced by ftrace or p= erf. It does show something (I'm interested in stap probe "guest_hypertrace", ra= ised on function "trace_guest_hypertrace"), but is incorrect: 50.00% (55e36d5ee32b) __cpu=3D0x55e370446fd0 arg1=3D0xcafe 50.00% (55e36d5ee32b) __cpu=3D0x7f2ee0a10b20 arg1=3D0x198 My test app calls "trace_guest_hypertrace" twice, always with the same "__c= pu" and "arg1" argument values. Just in case, this is runnign a QEMU compiled w= ith "-O0". Running "record" multiple times shows different "random" values on the arguments, and keeps changing which of the two trace elements shows incorre= ct values. Thanks, Lluis