[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v2 0/7] QEMU binary instrumentation prototyp
Re: [Qemu-devel] [RFC PATCH v2 0/7] QEMU binary instrumentation prototype
Sat, 8 Sep 2018 01:57:19 +0100
On 7 September 2018 at 15:39, Alex Bennée <address@hidden> wrote:
> Pavel Dovgalyuk <address@hidden> writes:
>> The following series implements dynamic binary instrumentation upon
> OK I've done a pass through the patches, final comments bellow.
>> For the current patches the plugins should provide the following
>> - "needs" callback to check whether the specific instruction
>> should be instrumented by this plugin
>> - "run" callback which called before executing the instuction
> I think with a little re-jigging we could reduce this to a single run
> call which can then decide if it is going to deal with things in this
>> Our instrumentation subsystem exploits TCG helper mechanism to embed
>> callbacks into the translation blocks. These callbacks may be inserted
>> before the specific instructions.
>> The aim of submission of this series at that early stage is to get
>> the feedback which will guide the development process. We are faced
>> the following questions:
>> 1. Does every plugins should have its own callback embedded into the TB
>> (which will cause TB extra growth in case of multiple plugins),
>> or the instrumentation layer's callback should invoke the plugins
>> that wanted to instrument that specific instruction?
> The common case is having one plugin and I'd rather give the flexibility
> of what helper to call and how much information to give it to the plugin
> and deal with the potential to have multiple helper calls per
> instruction for the complex cases.
> Now I can see arguments against it from an interface complexity point of
> view but I think plugins should get access to the TCG functions so they
> can generate their own op sequences if need be and not have to call a
> helper at all if they don't need to.
I strongly disagree -- plugins should not have access to details
of QEMU internals that might change from version to version, and
definitely not access to generating their own TCG code.