From: "Alex Bennée" <alex.bennee@linaro.org>
To: Mikhail Tyutin <m.tyutin@yadro.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Richard Henderson <richard.henderson@linaro.org>,
"erdnaxe@crans.org" <erdnaxe@crans.org>,
"ma.mandourr@gmail.com" <ma.mandourr@gmail.com>
Subject: Re: Instruction virtual address in TCG Plugins
Date: Mon, 13 Nov 2023 20:58:34 +0000 [thread overview]
Message-ID: <87leb1xtdx.fsf@draig.linaro.org> (raw)
In-Reply-To: <d4f2713a4e2d45858c82ff2efb95f8a3@yadro.com> (Mikhail Tyutin's message of "Mon, 13 Nov 2023 18:33:48 +0000")
Mikhail Tyutin <m.tyutin@yadro.com> writes:
> Greetings,
>
> What is the right way to get virtual address of either translation block or instruction inside of TCG plugin? Does
> plugin API allow that or it needs some extension?
>
> So far I use qemu_plugin_tb_vaddr() inside of my block translation callback to get block virtual address and then
> pass it as 'userdata' argument into qemu_plugin_register_vcpu_tb_exec_cb(). I use it later during code execution.
> It works well for user-mode emulation, but sometimes leads to
> incorrect addresses in system-mode emulation.
You can use qemu_plugin_insn_vaddr and qemu_plugin_insn_haddr. But your
right something under one vaddr and be executed under another with
overlapping mappings. The haddr should be stable though I think.
> I suspect it is because of memory mappings by guest OS that changes virtual addresses for that block.
>
> I also looked at gen_empty_udata_cb() function and considered to extend plugin API to pass a program counter
> value as additional callback argument. I thought it would always give me valid virtual address of an instruction.
> Unfortunately, I didn't find a way to get value of that register in architecture agnostic way (it is 'pc' member in
> CPUArchState structure).
When we merge the register api you should be able to do that. Although
during testing I realised that PC acted funny compared to everything
else because we don't actually update the shadow register every
instruction.
>
> ---
> Mikhail
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2023-11-13 20:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 18:33 Instruction virtual address in TCG Plugins Mikhail Tyutin
2023-11-13 20:58 ` Alex Bennée [this message]
2023-11-14 9:14 ` Mikhail Tyutin
2023-11-14 10:57 ` Alex Bennée
2023-11-21 16:39 ` Mikhail Tyutin
2023-11-21 17:24 ` Alex Bennée
2023-11-22 12:28 ` Mikhail Tyutin
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=87leb1xtdx.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=erdnaxe@crans.org \
--cc=m.tyutin@yadro.com \
--cc=ma.mandourr@gmail.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).