From: "Alex Bennée" <alex.bennee@linaro.org>
To: Fei Wu <fei2.wu@intel.com>
Cc: richard.henderson@linaro.org, pbonzini@redhat.com,
erdnaxe@crans.org, ma.mandourr@gmail.com, qemu-devel@nongnu.org
Subject: Re: [PATCH 1/2] accel/tcg/plugin: export host insn size
Date: Thu, 06 Apr 2023 08:46:35 +0100 [thread overview]
Message-ID: <87v8i9jviv.fsf@linaro.org> (raw)
In-Reply-To: <20230406022751.757980-2-fei2.wu@intel.com>
Fei Wu <fei2.wu@intel.com> writes:
> The translation ratio of host to guest instruction count is one of the
> key performance factor of binary translation. TCG doesn't collect host
> instruction count at present, it does collect host instruction size
> instead, although they are not the same thing as instruction size might
> not be fixed, instruction size is still a valid estimation.
I'm not so sure about exposing this information to plugins because we
try to avoid leaking internal implementation details to plugins. Aside
from that the very act of instrumenting will increase the size of the
target buffer.
If your aim is to examine JIT efficiency what is wrong with the current
"info jit" that you can access via the HMP? Also I'm wondering if its
time to remove the #ifdefs from CONFIG_PROFILER because I doubt the
extra data it collects is that expensive.
Richard, what do you think?
>
> Signed-off-by: Fei Wu <fei2.wu@intel.com>
> ---
> accel/tcg/plugin-gen.c | 1 +
> include/qemu/plugin.h | 2 ++
> include/qemu/qemu-plugin.h | 8 ++++++++
> plugins/api.c | 5 +++++
> plugins/qemu-plugins.symbols | 1 +
> 5 files changed, 17 insertions(+)
>
> diff --git a/accel/tcg/plugin-gen.c b/accel/tcg/plugin-gen.c
> index 5efb8db258..4a3ca8fa2f 100644
> --- a/accel/tcg/plugin-gen.c
> +++ b/accel/tcg/plugin-gen.c
> @@ -881,6 +881,7 @@ bool plugin_gen_tb_start(CPUState *cpu, const DisasContextBase *db,
> ptb->haddr2 = NULL;
> ptb->mem_only = mem_only;
> ptb->mem_helper = false;
> + ptb->host_insn_size = &db->tb->tc.size;
>
> plugin_gen_empty_callback(PLUGIN_GEN_FROM_TB);
> }
> diff --git a/include/qemu/plugin.h b/include/qemu/plugin.h
> index bc0781cab8..b38fd139e1 100644
> --- a/include/qemu/plugin.h
> +++ b/include/qemu/plugin.h
> @@ -151,6 +151,8 @@ struct qemu_plugin_tb {
> /* if set, the TB calls helpers that might access guest memory */
> bool mem_helper;
>
> + uint64_t *host_insn_size;
> +
> GArray *cbs[PLUGIN_N_CB_SUBTYPES];
> };
>
> diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
> index 50a9957279..2397574a21 100644
> --- a/include/qemu/qemu-plugin.h
> +++ b/include/qemu/qemu-plugin.h
> @@ -336,6 +336,14 @@ void qemu_plugin_register_vcpu_insn_exec_inline(struct qemu_plugin_insn *insn,
> */
> size_t qemu_plugin_tb_n_insns(const struct qemu_plugin_tb *tb);
>
> +/**
> + * qemu_plugin_tb_n_insns() - query helper for host insns size in TB
> + * @tb: opaque handle to TB passed to callback
> + *
> + * Returns: address of host insns size of this block
If we went ahead with this we need to be very clear when you can call
this helper because the data will only be valid at certain points (which
is another argument against this).
> + */
> +void *qemu_plugin_tb_host_insn_size(const struct qemu_plugin_tb *tb);
> +
> /**
> * qemu_plugin_tb_vaddr() - query helper for vaddr of TB start
> * @tb: opaque handle to TB passed to callback
> diff --git a/plugins/api.c b/plugins/api.c
> index 2078b16edb..0d70cb1f0f 100644
> --- a/plugins/api.c
> +++ b/plugins/api.c
> @@ -188,6 +188,11 @@ size_t qemu_plugin_tb_n_insns(const struct qemu_plugin_tb *tb)
> return tb->n;
> }
>
> +void *qemu_plugin_tb_host_insn_size(const struct qemu_plugin_tb *tb)
> +{
> + return tb->host_insn_size;
> +}
> +
> uint64_t qemu_plugin_tb_vaddr(const struct qemu_plugin_tb *tb)
> {
> return tb->vaddr;
> diff --git a/plugins/qemu-plugins.symbols b/plugins/qemu-plugins.symbols
> index 71f6c90549..3e92c3b8ba 100644
> --- a/plugins/qemu-plugins.symbols
> +++ b/plugins/qemu-plugins.symbols
> @@ -39,6 +39,7 @@
> qemu_plugin_start_code;
> qemu_plugin_tb_get_insn;
> qemu_plugin_tb_n_insns;
> + qemu_plugin_tb_host_insn_size;
> qemu_plugin_tb_vaddr;
> qemu_plugin_uninstall;
> qemu_plugin_vcpu_for_each;
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2023-04-06 7:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 2:27 [PATCH 0/2] accel/tcg/plugin: host insn size for plugin Fei Wu
2023-04-06 2:27 ` [PATCH 1/2] accel/tcg/plugin: export host insn size Fei Wu
2023-04-06 7:46 ` Alex Bennée [this message]
2023-04-07 1:31 ` Wu, Fei
2023-04-10 10:46 ` Alex Bennée
2023-04-08 3:34 ` Richard Henderson
2023-04-10 10:36 ` Alex Bennée
2023-04-10 13:02 ` Wu, Fei
2023-04-11 7:27 ` Alex Bennée
2023-04-12 12:50 ` Wu, Fei
2023-04-12 13:28 ` Alex Bennée
2023-04-12 13:47 ` Wu, Fei
2023-04-17 11:11 ` Wu, Fei
2023-04-17 12:11 ` Alex Bennée
2023-04-17 13:01 ` Wu, Fei
2023-04-21 13:46 ` Wu, Fei
2023-04-06 2:27 ` [PATCH 2/2] plugins/hotblocks: add " Fei Wu
2023-04-06 7:54 ` Alex Bennée
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=87v8i9jviv.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=erdnaxe@crans.org \
--cc=fei2.wu@intel.com \
--cc=ma.mandourr@gmail.com \
--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).