From: Mikhail Tyutin <m.tyutin@yadro.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"richard.henderson@linaro.org" <richard.henderson@linaro.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: RE: [PATCH] accel/tcg: Expose translation block flags to plugins
Date: Thu, 14 Dec 2023 10:37:22 +0000 [thread overview]
Message-ID: <17a36db2c85e46b9bcb380eb6d1f4667@yadro.com> (raw)
In-Reply-To: <87edfrd2yw.fsf@draig.linaro.org>
Hi Alex,
> > Exposing appropriate translation block flag allows plugins to
> > handle "memory only" blocks in appropriate way.
>
> We don't want to expose internal details to the plugin. It shouldn't
> need to care.
>
> Do you have a test case where you missed counting the execution of the
> instruction?
To speedup plugin execution time we want to shift processing logic to
block translation phase and keep execution callback light. Also moving
instrumentation at block level as opposite to instruction level, helps
to speedup up execution as well.
Given that, we prepare structures in translation callback. For example:
void handleBlockTranslation(qemu_plugin_id_t, qemu_plugin_tb* tblock)
{
BlockStats* s = new BlockStats();
s->init(tblock);
g_stats->append(s);
/* Then, insert execution callbacks and pass BlockStats as
userdata for quick data lookup in run time at:
1) basic block prologue:
qemu_plugin_register_vcpu_tb_exec_cb(tblock, cb, flags, s);
2) memory load/store:
qemu_plugin_register_vcpu_mem_cb(tblock, cb, flags,
mem_flags, s);
*/
}
Having artificial "mem only" block leads to allocation of new
BlockStats and memory access will be attributed to that block instead
of "original" one which is supposed to be executed. If we know that
block is "mem only" on translation phase, then memory callback is
implemented differently to find relevant BlockStats.
--
Mikhail
next prev parent reply other threads:[~2023-12-14 10:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 12:16 [PATCH] accel/tcg: Expose translation block flags to plugins Mikhail Tyutin
2023-12-12 12:23 ` Alex Bennée
2023-12-14 10:37 ` Mikhail Tyutin [this message]
2023-12-15 11:39 ` Alex Bennée
2023-12-12 12:43 ` 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=17a36db2c85e46b9bcb380eb6d1f4667@yadro.com \
--to=m.tyutin@yadro.com \
--cc=alex.bennee@linaro.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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).