From: "Alex Bennée" <alex.bennee@linaro.org>
To: Aaron Lindsay <aaron@os.amperecomputing.com>
Cc: cota@braap.org, richard.henderson@linaro.org, qemu-devel@nongnu.org
Subject: Re: Detecting Faulting Instructions From Plugins
Date: Thu, 11 Feb 2021 17:27:35 +0000 [thread overview]
Message-ID: <87k0resecj.fsf@linaro.org> (raw)
In-Reply-To: <YB1nf/M613d0B+Pm@strawberry.localdomain>
Aaron Lindsay <aaron@os.amperecomputing.com> writes:
> On Feb 05 15:03, Alex Bennée wrote:
>> Aaron Lindsay <aaron@os.amperecomputing.com> writes:
>> > Assuming you're right that TCG is detecting "a io_readx/io_writex when
>> > ->can_do_io is not true", could we detect this case when it occurs and
>> > omit the instruction callbacks for the re-translation of the single
>> > instruction (allow the initial callback to stand instead of trying to
>> > turn back time, in a way, to prevent it)? Maybe there would have be some
>> > bookkeeping in the plugin infrastructure side rather than entirely
>> > omitting the callbacks when re-translating, in case that translation got
>> > re-used in a case which didn't hit the same behavior and shouldn't be
>> > skipped?
>>
>> They are happening in two separate phases. The translation phase has no
>> idea what the runtime condition will be. Once we get to runtime it's too
>> late - and we trigger a new translation phase.
>
> I believe I understand why we can't catch the initial translation. To
> make sure I'm communicating well, my current understanding is that the
> timeline for this case goes something like:
>
> 1) translate large block of instructions, including ldr
> 2) attempt to execute ldr, calling instruction callback
> 3) notice that access is to IO, trigger re-translation of single
> ldr instruction
> 4) execute block with single ldr instruction to completion, calling both
> instruction and memory callbacks
>
> I was wondering if it would be possible to inform the re-translation in
> step 3 that it's for a re-translated IO access so that it could
> ultimately cause the second of the duplicate instruction callbacks to be
> omitted during execution in 4.
This is what I've done - re-executed blocks are compiled with CF_NOINSTR
which skips any instrumentation. If you could test the series I posted and
confirm the problem is solved that would be great:
Subject: [PATCH v2 00/21] plugins/next pre-PR (hwprofile, regression fixes, icount count fix)
Date: Wed, 10 Feb 2021 22:10:32 +0000
Message-Id: <20210210221053.18050-1-alex.bennee@linaro.org>
--
Alex Bennée
next prev parent reply other threads:[~2021-02-11 17:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-30 3:23 Detecting Faulting Instructions From Plugins Aaron Lindsay
2021-01-30 18:55 ` Aaron Lindsay
2021-02-01 12:07 ` Alex Bennée
2021-02-04 21:31 ` Aaron Lindsay
2021-02-05 11:19 ` Alex Bennée
2021-02-05 14:26 ` Aaron Lindsay via
2021-02-05 15:03 ` Alex Bennée
2021-02-05 15:33 ` Aaron Lindsay via
2021-02-05 15:42 ` Aaron Lindsay via
2021-02-05 16:41 ` Alex Bennée
2021-02-11 17:27 ` Alex Bennée [this message]
2021-02-11 18:35 ` Aaron Lindsay via
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=87k0resecj.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=aaron@os.amperecomputing.com \
--cc=cota@braap.org \
--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).