[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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2 0/5] backdoor: lightweight guest-to-QEMU backdoor channel
Date: Wed, 7 Dec 2011 18:51:47 +0000

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

-- PMM

reply via email to

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