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

[Lluís Vilanova]

Stefan Hajnoczi writes:

> 2011/12/8 Lluís Vilanova <address@hidden>:
>> 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).

Right. That's where instrumentation would come in handy.


>>> 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)?

I agree that tracing events in general are not an API, but you can add some
sufficiently generic events that can be used as such.

The main idea is to have some well-documented and target-agnostic events that
can be easily instrumented. As an example of this, you can have a look at a
patch series I just sent with some simple TCG-aware events:

 * vbbl
   Virtual address of a basic block that is going to be executed (QEMU TB).

 * vfetch
   Virtual address of an instruction that is going to be executed.

 * vmem
   Virtual address, size and mode of a memory access that is going to be
   performed.

Some other events that are half-cooked on my branch:

 * plvl
   Privilege-level change (x86-only).

 * aspace
   Address-space (page table) change (x86-only).

 * intr
   SW/HW interrupt or exception.

 * vfetch_info
   Extended instruction information (instruction size and set of used/defined
   architectural registers).

Other info that might be useful to add:

 * pbbl, pfetch, pmem (to avoid adding all the information on a single
   heavy-weight event)
   Physical address information. I already had a look at it,
   and my thoughts were to add the guest physical address info in the TLB
   entries if there's an enabled event requiring it.

 * vfetch_info
   Instruction opcode category (e.g., floating point, branch, alu, etc.). Hard
   to get on some architectures like x86.

 * cflow
   Control-flow instruction and its type (conditional, indirect, taken, etc.)
   and target address (probably hard to get it right, like opcodes)

 * *_end (or similar)
   The after-the-action counterpart of most of the other events (e.g.,
   bbl_end). There could be problems to get it right when there's a branch in
   the guest; besides, the next bbl/fetch/intr event would already signal the
   end/error of the previous event.


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth