Re: [Qemu-devel] Guest to Qemu communication channel + static instrumentation

[Lluís]

Anthony Liguori writes:

> On 07/08/2010 12:49 PM, Lluís wrote:
>> Hi there.
>> 
>> I'm porting into qemu some code I had for bochs. For this purpose, the first
>> part is a backdoor communication channel, such that code in the guest will be
>> able to directly communicate with qemu in a pre-defined manner (namely, the
>> decode of an illegal instruction).
>> 

> At least for x86, there is a well defined instruction for these purposes 
> (vmcall and vmmcall respectively).  I think qemu implementing 
> vmcall/vmmcall emulation for TCG is not a bad idea.

I don't think that's a good idea. Any instruction that is documented as
non-illegal could be used by emulated code, so I think this necessarily needs to
be somewhere that "normal" code wouldn't get into.

The easiest way is to add a new instruction that is effectively documented as
illegal. Another option is to use illegal addresses, but that's not so reliable,
and is more intrusive, as it would need cooperation from the OS (in full-system
mode).


>> This other piece is a set of static instrumentation points using macros that 
>> the
>> user can re-define at compile time.
>> 
>> For an example of how it would look like:
>> http://bochs.sourceforge.net/cgi-bin/lxr/source/instrument/
>> 

> It's not immediately clear to me how this would map to TCG so I'm 
> unclear about it's utility.

Ok, my current prototype contains calls to macros like:

    INSTR_FETCH(instruction address,
                instruction length,
                used registers,
                defined registers,
                opcode)

    INSTR_MEM(memory address,
              access length,
              read or write)

in the instruction translation code.

If, for example, the user is interested on the information provided by
INSTR_MEM, this can be re-defined and used as a point to generate TCG code to
call user-provided helpers.

In fact, that macro can execute and generate arbitrary code, but some
boilerplate macros are provided to easily generate TCG code to call
user-provided helper functions, and checking if that TCG code should really be
generated.

That last condition is controlled through the backdoor communication channel,
and lets the guest code control when, during the emulation, the helper code
should be called.

The result? The user can provide code to trace instructions, memory accesses,
etc, which is the kind of information that I later use on an architecture
simulator.

My proposal is to simply provide the bare instrumentation points in qemu
(leaving to the user all the details of what and how to record information), the
programmatic interface to control the dynamic activation of those points, and
the backdoor communication channel.

The advantage is that qemu already supports full-system and standalone
application emulation, as well as many guest architectures.

I'm sure others would gladly benefit from this, but the question is whether
you think this should be merged into qemu.

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