[lttng-dev] [Qemu-devel] [PATCH 0/6] hypertrace: Lightweight guest-to-QEMU trace channel

[Lluís Vilanova]

Stefan Hajnoczi writes:

> On Mon, Aug 29, 2016 at 08:46:02PM +0200, Lluís Vilanova wrote:
>> >> Also, I'm still not sure how to interact with QEMU's monitor interface from
>> >> within the probe code (probes execute in kernel mode, including "guru mode"
>> >> 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 </home/lluis/Projects/qemu-dbi-test/test.h>
>> %}
>> 
>> function event:long(cpu:long, addr:long, info:long)
>> %{
>> char *argv[4] = {"/bin/sh", "-c", "echo 'trace-event * off' | telnet 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?

> 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 happened.
> I've never had this issue before so maybe something with Debian
> SystemTap userspace probes is broken.

I already debugged it, to the point where QEMU executes the trap injected by
systemtap, and the register values that were supposed to hold the arguments are
correct.

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.


Thanks,
  Lluis