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

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

[Lluís]

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

Right now, this comes with a '--with-backdoor=PATH' flag in the configure
script, which lets the user activate the communication channel, and make qemu
compile all '.c' files in PATH as target code.

In those files, the user can place any code, plus backdoor callbacks (these are
a must), which are free to interact with any other piece of code in qemu.

Are you interested on merging this kind of functionality?

The only reason for this is to control the behaviour of the other piece of code
I'm working on (which I would very much like to integrate into qemu).

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/

Read you,
     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

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

[Anthony Liguori]

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.

> Right now, this comes with a '--with-backdoor=PATH' flag in the configure
> script, which lets the user activate the communication channel, and make qemu
> compile all '.c' files in PATH as target code.
>
> In those files, the user can place any code, plus backdoor callbacks (these are
> a must), which are free to interact with any other piece of code in qemu.
>
> Are you interested on merging this kind of functionality?
>
> The only reason for this is to control the behaviour of the other piece of code
> I'm working on (which I would very much like to integrate into qemu).
>
> 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.

Regards,

Anthony Liguori

> Read you,
>       Lluis
>
>    

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