plugin order of registration and order of callback

plugin order of registration and order of callback

[Robert Henry]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

The documentation on the new plugin capabilities of qemu is silent about the order call back registration should be done, and is also silent on the order in which call backs are fired.

Case in point: The callback registered by qemu_plugin_register_vcpu_mem_cb is called after the call back registered by qemu_plugin_register_vcpu_insn_exec_cb, regardless of the order of registration.

However, I'd like to have the insn_exec_cb called after the mem_cb so that I can save the mem information to be consumed by the insn callback.


[-- Attachment #2: Type: text/html, Size: 1446 bytes --]

Re: plugin order of registration and order of callback

[Alex Bennée]

Robert Henry <robhenry@microsoft.com> writes:

> The documentation on the new plugin capabilities of qemu is silent
> about the order call back registration should be done, and is also
> silent on the order in which call backs are fired.

Call-back order is based on the events themselves not the order of
registration. The only real order constraint is instruction
instrumentation has to be done from a translation call-back as that is
the point you can query what instructions are being processed.

But you are right the documentation is silent on the details because you
shouldn't need to know about the internals of TCG for the
instrumentation to work. We can certainly make this clearer in the docs
though.

> Case in point: The callback registered by
> qemu_plugin_register_vcpu_mem_cb is called after the call back
> registered by qemu_plugin_register_vcpu_insn_exec_cb, regardless of
> the order of registration.

With that in mind we should say instruction callbacks are always before
the instruction executes. The reason being is some instructions can
fault and exit the run loop so any instrumentation inserted afterwards
will never execute.

Internally instruction instrumentation is done on instruction boundaries
while memory instrumentation is done on individual TCG operations (of
which several can be involved in an instruction). However plugins
shouldn't rely on this knowledge as we want to be free to change TCG
internals.

> However, I'd like to have the insn_exec_cb called after the mem_cb so
> that I can save the mem information to be consumed by the insn
> callback.

This is what udata is for. Create a shared structure for the instruction
information and pass it to both the mem and insn callback functions.
However not all instructions will generate mem callbacks and you will
also want to ensure you track the cpu_index in -smp > 1 tests so you
don't confuse data for the same instruction on multiple cores.

You may not even need to install the callback for the instruction if you
store the information you need at instrumentation time. It's hard to
know without some more background on what you are trying to do.

-- 
Alex Bennée

Re: plugin order of registration and order of callback

[Peter Maydell]

On Fri, 10 Jan 2020 at 12:15, Alex Bennée <alex.bennee@linaro.org> wrote:
> With that in mind we should say instruction callbacks are always before
> the instruction executes. The reason being is some instructions can
> fault and exit the run loop so any instrumentation inserted afterwards
> will never execute.

I suppose in theory we could also have an "instruction retired
successfully" event (by analogy with the h/w perf events that
some architectures have), if it's generally useful; it sounds
like it wouldn't solve the problem here though.

thanks
-- PMM