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

[Anthony Liguori]

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.

Regards,

Anthony Liguori

> -- PMM