qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-devel@nongnu.org
Subject: Re: plugin order of registration and order of callback
Date: Fri, 10 Jan 2020 12:14:32 +0000	[thread overview]
Message-ID: <87eew7ik47.fsf@linaro.org> (raw)
In-Reply-To: <MW2PR2101MB1035A21608E50D68EE1CF890D63C0@MW2PR2101MB1035.namprd21.prod.outlook.com>


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


  reply	other threads:[~2020-01-10 12:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-06 22:41 plugin order of registration and order of callback Robert Henry
2020-01-10 12:14 ` Alex Bennée [this message]
2020-01-12 20:35   ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eew7ik47.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).