From: Peter Maydell <peter.maydell@linaro.org>
To: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: "Sergey Fedorov" <serge.fdrv@gmail.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Greg Bellows" <greg.bellows@linaro.org>
Subject: Re: [Qemu-devel] [PATCH v2 9/9] target-arm: Add WFx instruction trap support
Date: Thu, 23 Apr 2015 11:57:10 +0100 [thread overview]
Message-ID: <CAFEAcA8QXQVH1VSWP=xuY10oAda2-g7oESsjXv682jBGYNwpUw@mail.gmail.com> (raw)
In-Reply-To: <CAJy5ezqzHVwgHfmkxSDk4yDZb-6zoiU-cxeBNkUWSAF8Xj4GjQ@mail.gmail.com>
On 23 April 2015 at 11:39, Edgar E. Iglesias <edgar.iglesias@gmail.com> wrote:
>
> On 23/04/2015 6:00 pm, "Peter Maydell" <peter.maydell@linaro.org> wrote:
>> In theory you could maybe check has_work() for the WFI case,
>> since doing an EXCP_HLT really should cause us to stop until
>> has_work is true, but it seems a bit fragile -- could we really
>> guarantee that nothing would change between this point and
>> when we went back through the main loop that would change
>> whether has_work evaluates true or not? I think that it's better
>> there too to just always take the trap: setting EXCP_HLT is our
>> "going into a low power state" and so we should take the trap
>> if we would otherwise have done that.
>
> I think functional wise we are OK.
> The implementation can AFAIK always choose to nop for whatever reason (e.g
> has_work()). Only when we choose to enter low power, the trap comes into
> play.
Ah, so in helper_wfi() do something like
if (!has_work()) {
if (trapping wfi) {
EXCP_UDEF code;
} else {
EXCP_HALT code;
}
}
/* otherwise just return, making this WFI a nop */
?
I think that would work.
> Maybe wfe is the most problematic one because it fires more frequently and
> often when has_work() is true?
Yes, I think we should start by not trapping on WFE and then look
at how good/bad perf is.
-- PMM
next prev parent reply other threads:[~2015-04-23 10:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-22 17:09 [Qemu-devel] [PATCH v2 0/9] target-arm: EL3 trap support Greg Bellows
2015-04-22 17:09 ` [Qemu-devel] [PATCH v2 1/9] target-arm: Add exception target el infrastructure Greg Bellows
2015-04-22 17:09 ` [Qemu-devel] [PATCH v2 2/9] target-arm: Extend helpers to route exceptions Greg Bellows
2015-04-22 17:09 ` [Qemu-devel] [PATCH v2 3/9] target-arm: Update interrupt handling to use target EL Greg Bellows
2015-04-22 17:09 ` [Qemu-devel] [PATCH v2 4/9] target-arm: Add AArch64 CPTR registers Greg Bellows
2015-05-18 17:32 ` Peter Maydell
2015-04-22 17:09 ` [Qemu-devel] [PATCH v2 5/9] target-arm: Extend FP checks to use an EL Greg Bellows
2015-05-18 17:40 ` Peter Maydell
2015-04-22 17:09 ` [Qemu-devel] [PATCH v2 6/9] target-arm: Add TTBR regime function and use Greg Bellows
2015-04-22 18:16 ` Sergey Fedorov
2015-04-22 18:23 ` Greg Bellows
2015-04-22 17:09 ` [Qemu-devel] [PATCH v2 7/9] target-arm: Add EL3 and EL2 TCR checking Greg Bellows
2015-04-22 17:09 ` [Qemu-devel] [PATCH v2 8/9] target-arm: Add WFx syndrome function Greg Bellows
2015-04-22 17:09 ` [Qemu-devel] [PATCH v2 9/9] target-arm: Add WFx instruction trap support Greg Bellows
2015-04-23 2:49 ` Edgar E. Iglesias
2015-04-23 7:59 ` Peter Maydell
2015-04-23 10:39 ` Edgar E. Iglesias
2015-04-23 10:57 ` Peter Maydell [this message]
2015-04-23 11:24 ` Edgar E. Iglesias
2015-04-23 11:28 ` Peter Maydell
2015-04-23 11:34 ` Edgar E. Iglesias
2015-04-23 14:26 ` Greg Bellows
2015-04-23 14:30 ` Peter Maydell
2015-04-23 14:41 ` Greg Bellows
2015-04-23 14:51 ` Peter Maydell
2015-04-23 15:00 ` Greg Bellows
2015-04-23 15:11 ` Peter Maydell
2015-04-23 3:37 ` [Qemu-devel] [PATCH v2 0/9] target-arm: EL3 " Edgar E. Iglesias
2015-04-23 8:06 ` Peter Maydell
2015-04-23 10:10 ` Peter Maydell
2015-04-23 10:27 ` Edgar E. Iglesias
2015-04-23 14:05 ` Greg Bellows
2015-05-18 17:53 ` Peter Maydell
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='CAFEAcA8QXQVH1VSWP=xuY10oAda2-g7oESsjXv682jBGYNwpUw@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=edgar.iglesias@gmail.com \
--cc=greg.bellows@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=serge.fdrv@gmail.com \
/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).