Re: [Qemu-devel] [RFC PATCH v2 0/7] QEMU binary instrumentation prototype

[Peter Maydell]

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
>> QEMU.
>
> OK I've done a pass through the patches, final comments bellow.
>
> <snip>
>>
>> For the current patches the plugins should provide the following
>> callbacks:
>>  - "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
> case.
>
>> 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.

thanks
-- PMM