Re: [Qemu-devel] [PATCH v2 0/5] backdoor: lightweight guest-to-QEMU backdoor channel

[Stefan Hajnoczi <stefanha@gmail.com>]

2011/12/8 Lluís Vilanova <vilanova@ac.upc.edu>:
> Stefan Hajnoczi writes:
> [...]
>>> * Support for tracing guest code through TCG.
>
>> I'm not clear on whether a backdoor mechanism is needed or not.  A
>> backdoor mechanism allows a modified guest to participate in tracing.
>
>> Depending on the type of analysis you are doing it might be possible
>> to achieve the same thing by emitting calls to custom instrumentation
>> in TCG (or is this too low-level for what you're trying to trace in
>> the guest?).  The advantage is also that you can do this to unmodified
>> guests.
>
> You're right with the first; it exists for two reasons:
>
> * simplicity: it's easier to have, for example, a backdoor + linux tracepoints
>  than obtaining the IP of an "interesting" function (think of the
>  multiprogramming on a full system)
>
> * performance: it's faster to let the guest tell you rather than (ab)using
>  breakpoints or checking the IP of every instruction
>
> The main use of this is to get semanticful events on the guest (my previous
> example was about knowing when linux changes the current process, but you could
> use anything else as well - e.g., a certain function of a specific thread on the
> guest -).

I misunderstood the layer you were tracing.  A backdoor into the guest
indeed makes high-level events easy.

My thoughts were more along the lines of TCG planting calls to custom
functions when it translates an instruction of interest, which is much
lower level and would be more appropriate for code execution
statistics (branches, counters, etc).

>> So I'm suggesting that we don't *need* explicit support for
>> instrumenting trace events.  Instead add plain old functions where you
>> need them.  You may decide to invoke trace events from your
>> instrumentation function, but that's already covered today by
>> docs/tracing.txt.
>
>> Am I missing the point of instrumentation tracing events or do you
>> agree that we can work well without it?
>
> The point is to avoid diving into QEMU's code and instead use the current
> out-of-the-box tracing points as the instrumentation hooks, which can be
> achieved both through the current approach or an unofficial tracing backend.
>
> The nice thing about the current approach is that the user can do some extra
> checks on the tracing event and then (maybe) call the original backend-generated
> tracing routine (as a quick and easy way to extend what to actually trace).

The workflow with an instrumentation layer and trace events as API:
1. Look at available trace events.
2. Write function against trace event interface without using QEMU internals.
3. If you want tracing output make sure to invoke trace_*_backend()
after any processing/filtering.

The workflow in my mind is:
1. Look at QEMU source for a place to insert instrumentation.
2. Write a plain old function (nothing to do with QEMU tracing) to
perform your instrumentation.
3. If you want tracing output make sure to invoke trace_*() after any
processing/filtering.

Although I now understand the purpose of the instrumentation layer
better - it insulates from QEMU's guts - I'm not really of fan of this
approach because I don't see trace events as an API.  They are not
documented and require looking at call sites in QEMU source code to
understand their meaning.  My argument is that once you need to look
inside QEMU to understand how to instrument there is no benefit from
having an instrumentation layer.

We have no API on which to build the instrumentation interface.  Can
you give details about the APIs you'd like and how you use them (e.g.
mem_read()/mem_write() for instrumenting guest memory accesses)?

Stefan