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

[Lluís Vilanova]

Anthony Liguori writes:

> On 12/07/2011 12:51 PM, Peter Maydell wrote:
>> 2011/12/7 Lluís Vilanova<address@hidden>:
>>> Anthony Liguori writes:
>>> [...]
>>>> Why should this analyzer live outside of QEMU in the first place?  I fail 
>>>> to see
>>>> the rationale for that other than not wanting to do the work of making it
>>>> suitable for upstream consumption.
>>> 
>>> For the same reason that SystemTap lets you add user-provided code into the
>>> trace hooks, you never know what the user actually wants. The difference is 
>>> that
>>> when dealing with traces that require a high bandwidth, different people 
>>> may be
>>> interested on analyzing different events and under different conditions, and
>>> having a JIT in QEMU comes in handy to optimize the traces. This includes 
>>> the
>>> generation of extra tracing code at translation time (e.g., I generate 
>>> checks in
>>> TCG to establish when I want to trace a specific event, and someone else may
>>> just want to increment a counter using TCG code).
>>> 
>>> Guest trace instrumentation turns QEMU into a highly-performant tool for 
>>> dynamic
>>> binary instrumentation, with all the benefits that stem from QEMU (support 
>>> for a
>>> myriad of target architectures, as well as support for both full-system and
>>> user-level applications).
>> 
>> I think this *is* useful. However I also think that it *is* effectively
>> defining an API for people writing this hook code, and as such we ought
>> to do it properly if we're going to do it. (ie nail down what we are
>> providing for hook authors and don't let them grub around in the internals
>> otherwise).

> I strongly suspect that you could define interfaces in QEMU such that you 
> could
> do most of what you want without needing to link any code against QEMU itself.

> This is probably a case where LUA integration might make a lot of sense.

Sure you can provide an API for instrumentors. It's just that defining a stable
API for that would require me at least an order of magnitude more effort, and
this is time I don't have right now.

The other problem here is that of performance.

During translation, it is basically dependant on TB reusability, plus the
possibility to optimize the analyzer code when it's inlined into QEMU and some
of its arguments are known at compile-time. I just don't have numbers on that.

During execution it is way more sensitive, thus my approach to build the
analyzer code into QEMU. Otherwise you would go through a LUA interpreter (or
anything else) or, in the best case, a conditional indirect call
(dlopen).

>From my experience, these are the basics I need:

* Decide what to do when an event is translated (by default - no instrumentation
  -, it just generates a TCG call to an execution-time tracing routine).

  This includes:

  * Deciding whether to generate the TCG call to the execution-time tracing
    routine.

  * Access to generating other arbitrary TCG code (the API is pretty stable, but
    headers depend on target-specific defines).

    This could also include generating code like incrementing a counter (e.g.,
    when counting instructions), instead of calling the execution-time tracing
    routine.

    My library actually hides this from the user, who just provides conditions
    to establish whether to trace the event. Then the library automatically
    establishes whether it's best to evaluate each condition at translation
    time, using TCG code or when the execution-time tracing routine is invoked.

  * [still don't have it] Access to a map between target-specific abstractions
    (mainly register names) and TCG values (e.g., to generate code that gets or
    sets the value of a well-known register).

* Decide what to do when an event is executed, including calls to execution-time
  event tracing routines generated by TCG code (by default, it just calls the
  tracing backend).

  This includes:

  * Arbitrary user-provided code (the analysis itself when not inlined with
    TCG).

  * [still don't have it] Access to get and set the values of target-specific
    abstractions (mainly registers).

* Add a per-vCPU opaque pointer with data private to the analyzer code.


Other things might include the injection of interrupts or anything else related
to the guest.


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