[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v2 0/5] backdoor: lightweight guest-to-QEMU backdoor channel
Date: Wed, 07 Dec 2011 12:54:23 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

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

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.


Anthony Liguori

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]