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
