qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lluís Vilanova
Subject: Re: [Qemu-devel] [PATCH 0/6] hypertrace: Lightweight guest-to-QEMU trace channel
Date: Tue, 06 Sep 2016 10:54:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Daniel P Berrange writes:

> On Mon, Sep 05, 2016 at 08:29:54PM +0200, Lluís Vilanova wrote:
>> Daniel P Berrange writes:
>> 
>> > On Mon, Aug 29, 2016 at 08:46:02PM +0200, Lluís Vilanova wrote:
>> >> Stefan Hajnoczi writes:
>> >> 
>> >> > 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);
>> >> %}
>> 
>> > I don't know what you're trying to achieve here.  The trace-event state,
>> > as changed/viewed via QEMU monitor, is irrelevant to the dtrace (systemtap)
>> > backend. dtrace and ltt-ust are both fully dynamic trace event backends,
>> > so the QEMU event state has no effect on them. The probe points in the
>> > binary are dynamically enabled / disabled by the dtrace runtime. ie dtrace
>> > will automatically enable an event if you write a dtrace script that uses
>> > the event.
>> 
>> Sorry, I did not properly explain the use case. This is an example of using
>> QEMU's tracing infrastructure to control itself. Here I'm using the "log"
>> backend to trace events to disk, and the "dtrace" backend (systemtap) to 
>> control
>> the tracing state of such events.

> Ah, I see. I guess I'd personally just have systemtap/dtrace directly emit
> the data to be recorded, and avoid the log backend entirely.

Backends with a buffered output stream like "simple" should be faster than
"dtrace", which AFAIK injects a software trap. Also, you can take advantage of
existing QEMU infrastructure to control the tracing of events, instead of
implementing your own on each script.

Cheers,
  Lluis



reply via email to

[Prev in Thread] Current Thread [Next in Thread]