From: "Alex Bennée" <alex.bennee@linaro.org>
To: Richard Henderson <rth@twiddle.net>
Cc: Peter Maydell <peter.maydell@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
qemu-arm <qemu-arm@nongnu.org>,
Etienne Carriere <etienne.carriere@linaro.org>,
Joakim Bech <joakim.bech@linaro.org>,
"Emilio G . Cota" <cota@braap.org>
Subject: Re: [RFC PATCH] target/arm: ensure eret exits the run-loop
Date: Mon, 10 Jul 2017 13:15:06 +0100 [thread overview]
Message-ID: <87tw2ka3p1.fsf@linaro.org> (raw)
In-Reply-To: <638cda88-5bd8-2a86-d720-04005fa1c1c8@twiddle.net>
Richard Henderson <rth@twiddle.net> writes:
> On 07/07/2017 08:29 AM, Alex Bennée wrote:
>>> Naming all of these different exit conditions is certainly
>>> non-trivial.
>>
>> Given the variation of usage this is something that should probably be
>> done after Lluís common run loop goes in and we can beef up the
>> semantics of the various exit conditions.
>
> Definitely.
>
>> One thing I have noticed in the ARM translator is DISAS_UPDATE does a:
>>
>> gen_a64_set_pc_im(dc->pc);
>>
>> I think this is to deal with handling exceptions either side of various
>> instructions. Am I right in thinking this is superfluous now as we can
>> derive the PC from the translated code address?
>
> Yes and no.
>
> We have typically distinguished between two kinds of exceptions: those
> that are dynamic (fp state, page permissions) and those that are
> static (illegal opcodes).
>
> For the dynamic, we used to pessimistically save state, but now use
> the unwinder to restore it. The unwinding is expensive but is used
> infrequently (especially compared to the number of load/store insns
> executed).
>
> For the static, we know the exception must be raised, and we know the
> state that must be saved. By doing that, we save the expense of the
> unwinding.
>
> So, for the static case you're talking about, we could get the PC (and
> other state) back, and remove the explicit stores, but we shouldn't.
I'm thinking of how to bring this into line with the other translators.
Pretty much everyone else generates an exit block although m68k does do
a update_cc_op(dc); In the ARM translator we have the backend specific
DISAS_EXIT which behaves like DISAS_UPDATE everywhere else.
For consistency DISAS_UPDATE should work the same across all arches but
doing:
gen_set_pc_im(dc, dc->pc);
if we are going to use DISAS_UPDATE instead of DISAS_EXIT is going to
break things like eret as dc->pc will certainly not be the correct PC.
Looking at translate.c (32 bit arm), we have:
gen_srs
gen_mrs_banked
gen_msr_banked
These all manually set:
gen_set_pc_im(s, s->pc - 4);
before their respective helpers. I think setting the PC after the helper
is superfluous given we are will at that point be exiting the block. The
situation is the same for translate-a64.c. So I think the correct
changes are:
- strengthen commentary in exec-all.h
- don't set pc on our way out of a DISAS_UPDATE
- convert eret to DISAS_UPDATE
- get rid of DISAS_EXIT and use DISAS_UPDATE instead
My only worry is inadvertently breaking something because something does
need the post-foo set_pc. But I can't think what does. Peter?
--
Alex Bennée
WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Richard Henderson <rth@twiddle.net>
Cc: Peter Maydell <peter.maydell@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
qemu-arm <qemu-arm@nongnu.org>,
Etienne Carriere <etienne.carriere@linaro.org>,
Joakim Bech <joakim.bech@linaro.org>,
"Emilio G . Cota" <cota@braap.org>
Subject: Re: [Qemu-devel] [RFC PATCH] target/arm: ensure eret exits the run-loop
Date: Mon, 10 Jul 2017 13:15:06 +0100 [thread overview]
Message-ID: <87tw2ka3p1.fsf@linaro.org> (raw)
In-Reply-To: <638cda88-5bd8-2a86-d720-04005fa1c1c8@twiddle.net>
Richard Henderson <rth@twiddle.net> writes:
> On 07/07/2017 08:29 AM, Alex Bennée wrote:
>>> Naming all of these different exit conditions is certainly
>>> non-trivial.
>>
>> Given the variation of usage this is something that should probably be
>> done after Lluís common run loop goes in and we can beef up the
>> semantics of the various exit conditions.
>
> Definitely.
>
>> One thing I have noticed in the ARM translator is DISAS_UPDATE does a:
>>
>> gen_a64_set_pc_im(dc->pc);
>>
>> I think this is to deal with handling exceptions either side of various
>> instructions. Am I right in thinking this is superfluous now as we can
>> derive the PC from the translated code address?
>
> Yes and no.
>
> We have typically distinguished between two kinds of exceptions: those
> that are dynamic (fp state, page permissions) and those that are
> static (illegal opcodes).
>
> For the dynamic, we used to pessimistically save state, but now use
> the unwinder to restore it. The unwinding is expensive but is used
> infrequently (especially compared to the number of load/store insns
> executed).
>
> For the static, we know the exception must be raised, and we know the
> state that must be saved. By doing that, we save the expense of the
> unwinding.
>
> So, for the static case you're talking about, we could get the PC (and
> other state) back, and remove the explicit stores, but we shouldn't.
I'm thinking of how to bring this into line with the other translators.
Pretty much everyone else generates an exit block although m68k does do
a update_cc_op(dc); In the ARM translator we have the backend specific
DISAS_EXIT which behaves like DISAS_UPDATE everywhere else.
For consistency DISAS_UPDATE should work the same across all arches but
doing:
gen_set_pc_im(dc, dc->pc);
if we are going to use DISAS_UPDATE instead of DISAS_EXIT is going to
break things like eret as dc->pc will certainly not be the correct PC.
Looking at translate.c (32 bit arm), we have:
gen_srs
gen_mrs_banked
gen_msr_banked
These all manually set:
gen_set_pc_im(s, s->pc - 4);
before their respective helpers. I think setting the PC after the helper
is superfluous given we are will at that point be exiting the block. The
situation is the same for translate-a64.c. So I think the correct
changes are:
- strengthen commentary in exec-all.h
- don't set pc on our way out of a DISAS_UPDATE
- convert eret to DISAS_UPDATE
- get rid of DISAS_EXIT and use DISAS_UPDATE instead
My only worry is inadvertently breaking something because something does
need the post-foo set_pc. But I can't think what does. Peter?
--
Alex Bennée
next prev parent reply other threads:[~2017-07-10 12:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-07 16:18 [RFC PATCH] target/arm: ensure eret exits the run-loop Alex Bennée
2017-07-07 16:18 ` [Qemu-devel] " Alex Bennée
2017-07-07 17:32 ` Alex Bennée
2017-07-07 17:32 ` [Qemu-devel] " Alex Bennée
2017-07-07 17:36 ` Peter Maydell
2017-07-07 17:36 ` [Qemu-devel] " Peter Maydell
2017-07-07 17:54 ` Richard Henderson
2017-07-07 17:54 ` [Qemu-devel] " Richard Henderson
2017-07-07 18:29 ` Alex Bennée
2017-07-07 18:29 ` [Qemu-devel] " Alex Bennée
2017-07-07 18:52 ` Richard Henderson
2017-07-07 18:52 ` [Qemu-devel] " Richard Henderson
2017-07-08 16:21 ` [Qemu-arm] " Philippe Mathieu-Daudé
2017-07-08 16:21 ` [Qemu-devel] " Philippe Mathieu-Daudé
2017-07-10 12:15 ` Alex Bennée [this message]
2017-07-10 12:15 ` [Qemu-devel] " Alex Bennée
2017-07-10 12:19 ` Peter Maydell
2017-07-10 12:19 ` [Qemu-devel] " Peter Maydell
2017-07-10 12:54 ` Alex Bennée
2017-07-10 12:54 ` [Qemu-devel] " 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=87tw2ka3p1.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=cota@braap.org \
--cc=etienne.carriere@linaro.org \
--cc=joakim.bech@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.