On 7 September 2018 at 15:39, Alex Bennée <[email protected]> wrote: > > Pavel Dovgalyuk <[email protected]> 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
