qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Pierrick Bouvier <pierrick.bouvier@linaro.org>
To: Julian Ganz <neither@nut.email>, qemu-devel@nongnu.org
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	"Alexandre Iooss" <erdnaxe@crans.org>,
	"Mahmoud Mandour" <ma.mandourr@gmail.com>
Subject: Re: [PATCH v5 23/25] tests: add plugin asserting correctness of discon event's to_pc
Date: Tue, 20 May 2025 14:09:14 -0700	[thread overview]
Message-ID: <03a14875-170a-4897-a4fa-073fdfd1479f@linaro.org> (raw)
In-Reply-To: <4ea8edc376234e43230b09cb1b740616dee1652a@nut.email>

On 5/20/25 1:44 PM, Julian Ganz wrote:
> Hi Pierrick,
> 
> May 20, 2025 at 10:01 PM, Pierrick Bouvier wrote:
>> Regarding the issue with the same tb being mapped at different virtual addresses, I'm ok with the current solution of comparing only page bits.
>>
>> That said, a better solution could be to compare physical addresses when a discon is detected (on plugin side), and confirm it's really a discontinuity or just a different mapping. With this approach, it's not even needed to have a dedicated option, and there would be no false positive in the plugin. It's just a suggestion though.
> 
> I actually tried to do this before resorting to the current appraoch.
> However, there is only API for querying an instruction's or TB's
> hardware address and none that would let me translate the virtual
> addresses we receive in the discon callback, which we need to compare
> against.
>

It would be acceptable to add such a function allowing to query physical 
address for a virtual address (using cpu_get_phys_page_debug behind the 
hoods), as it's not leaking any QEMU implementation detail.

We can implement this later if you don't want to extend your series with 
this.

> I considered also passing the hardware address to the callback (do the
> translation in the `plugin_vcpu_cb__discon` hook), but that turned out
> to be not straight forward and not something we'd want to do in the
> hook, either.
>

Yes, in some cases, people will want virtual addresses, and sometimes 
physical ones. So passing physical ones only is too restrictive.

This plugin is a bit specific, as it's explicitely tracking all 
transitions between instructions, where a "normal" plugin will just work 
with discontinuities. That said, the use case to get physical address 
from a virtual one is a real need.

> Regards,
> Julian

Regards,
Pierrick


  reply	other threads:[~2025-05-20 21:10 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-19 15:19 [PATCH v5 00/25] tcg-plugins: add hooks for discontinuities Julian Ganz
2025-05-19 15:19 ` [PATCH v5 01/25] plugins: add types for callbacks related to certain discontinuities Julian Ganz
2025-05-24 16:43   ` Richard Henderson
2025-05-19 15:19 ` [PATCH v5 02/25] plugins: add API for registering discontinuity callbacks Julian Ganz
2025-05-24 16:48   ` Richard Henderson
2025-05-19 15:19 ` [PATCH v5 03/25] plugins: add hooks for new discontinuity related callbacks Julian Ganz
2025-05-24 16:55   ` Richard Henderson
2025-05-25 20:56     ` Julian Ganz
2025-05-26  8:08       ` Julian Ganz
2025-05-26  9:02         ` Richard Henderson
2025-05-24 17:27   ` Richard Henderson
2025-05-25 20:56     ` Julian Ganz
2025-05-19 15:19 ` [PATCH v5 04/25] contrib/plugins: add plugin showcasing new dicontinuity related API Julian Ganz
2025-05-19 15:19 ` [PATCH v5 05/25] target/alpha: call plugin trap callbacks Julian Ganz
2025-05-24 16:56   ` Richard Henderson
2025-05-25 12:14   ` Richard Henderson
2025-05-25 20:16     ` Julian Ganz
2025-05-26  9:01       ` Richard Henderson
2025-05-26  9:54         ` Julian Ganz
2025-05-26 16:22           ` Richard Henderson
2025-05-19 15:19 ` [PATCH v5 06/25] target/arm: " Julian Ganz
2025-05-24 17:05   ` Richard Henderson
2025-05-19 15:19 ` [PATCH v5 07/25] target/avr: " Julian Ganz
2025-05-24 17:06   ` Richard Henderson
2025-05-19 15:19 ` [PATCH v5 08/25] target/hppa: " Julian Ganz
2025-05-24 17:07   ` Richard Henderson
2025-05-24 23:19     ` Julian Ganz
2025-05-19 15:19 ` [PATCH v5 09/25] target/i386: " Julian Ganz
2025-05-19 15:19 ` [PATCH v5 10/25] target/loongarch: " Julian Ganz
2025-05-24 17:10   ` Richard Henderson
2025-05-19 15:19 ` [PATCH v5 11/25] target/m68k: " Julian Ganz
2025-05-24 17:19   ` Richard Henderson
2025-05-19 15:19 ` [PATCH v5 12/25] target/microblaze: " Julian Ganz
2025-05-24 17:21   ` Richard Henderson
2025-05-19 15:19 ` [PATCH v5 13/25] target/mips: " Julian Ganz
2025-05-24 17:23   ` Richard Henderson
2025-05-19 15:19 ` [PATCH v5 14/25] target/openrisc: " Julian Ganz
2025-05-24 17:25   ` Richard Henderson
2025-05-25 20:56     ` Julian Ganz
2025-05-19 15:19 ` [PATCH v5 15/25] target/ppc: " Julian Ganz
2025-05-24 17:30   ` Richard Henderson
2025-05-26 10:04     ` Julian Ganz
2025-05-19 15:19 ` [PATCH v5 16/25] target/riscv: " Julian Ganz
2025-05-19 15:19 ` [PATCH v5 17/25] target/rx: " Julian Ganz
2025-05-24 17:34   ` Richard Henderson
2025-05-19 15:19 ` [PATCH v5 18/25] target/s390x: " Julian Ganz
2025-05-24 17:36   ` Richard Henderson
2025-05-19 15:19 ` [PATCH v5 19/25] target/sh4: " Julian Ganz
2025-05-24 17:38   ` Richard Henderson
2025-05-19 15:20 ` [PATCH v5 20/25] target/sparc: " Julian Ganz
2025-05-24 17:41   ` Richard Henderson
2025-05-19 15:20 ` [PATCH v5 21/25] target/tricore: " Julian Ganz
2025-05-20 14:25   ` Bastian Koppelmann
2025-05-24 17:44   ` Richard Henderson
2025-05-19 15:20 ` [PATCH v5 22/25] target/xtensa: " Julian Ganz
2025-05-19 15:24 ` [PATCH v5 23/25] tests: add plugin asserting correctness of discon event's to_pc Julian Ganz
2025-05-20 20:01   ` Pierrick Bouvier
2025-05-20 20:44     ` Julian Ganz
2025-05-20 21:09       ` Pierrick Bouvier [this message]
2025-05-21 19:03         ` Pierrick Bouvier
2025-05-19 15:24 ` [PATCH v5 24/25] tests: add test for double-traps on rv64 Julian Ganz
2025-05-19 15:24 ` [PATCH v5 25/25] tests: add test with interrupted memory accesses " Julian Ganz
2025-09-02 10:20 ` [PATCH v5 00/25] tcg-plugins: add hooks for discontinuities Alex Bennée
2025-09-02 11:49   ` Julian Ganz

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=03a14875-170a-4897-a4fa-073fdfd1479f@linaro.org \
    --to=pierrick.bouvier@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=erdnaxe@crans.org \
    --cc=ma.mandourr@gmail.com \
    --cc=neither@nut.email \
    --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).