All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
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 20:39:06 +1000	[thread overview]
Message-ID: <CAJy5ezqzHVwgHfmkxSDk4yDZb-6zoiU-cxeBNkUWSAF8Xj4GjQ@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA_0j3mtqrORwV38sTCyYk7BWQPi0EmGks60MRqeYO=D3Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2430 bytes --]

On 23/04/2015 6:00 pm, "Peter Maydell" <peter.maydell@linaro.org> wrote:
>
> On 23 April 2015 at 03:49, Edgar E. Iglesias <edgar.iglesias@gmail.com>
wrote:
> > On Wed, Apr 22, 2015 at 12:09:21PM -0500, Greg Bellows wrote:
> >>  void HELPER(wfe)(CPUARMState *env)
> >>  {
> >>      CPUState *cs = CPU(arm_env_get_cpu(env));
> >> +    int target_el = check_wfx_trap(env, true);
> >>
> >>      /* Don't actually halt the CPU, just yield back to top
> >>       * level loop
> >>       */
> >> -    cs->exception_index = EXCP_YIELD;
> >> +    if (target_el) {
> >> +        cs->exception_index = EXCP_UDEF;
> >> +        env->exception.syndrome = syn_wfx(1, 0xe, true);
> >> +        env->exception.target_el = target_el;
> >> +        env->pc -= 4;
> >> +    } else {
> >> +        cs->exception_index = EXCP_YIELD;
> >> +    }
> >>      cpu_loop_exit(cs);
> >>  }
> >
> >
> > Hi Greg,
> >
> > Before trapping, don't you need to check that the CPU has no actual
work?
> > e.g:
> > if (!cc->has_work(cs) && ..)
>
> We don't track WFE-wakeup events, so we must always trap. (Well,
> I suppose strictly we could also go for "never trap" on the basis
> that really our implementation here is pretty much a NOP, but I
> think always-trap is closer to reasonable.)
>
> 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.

Maybe wfe is the most problematic one because it fires more frequently and
often when has_work() is true?

Cheers,
Edgar

>
> > I think you can still EXCP_YIELD the core if it has work though
> > as it's probably a good place to reschedule other CPUs in our
> > single-threaded SMP model.
>
> That is indeed the only reason we do anything with WFE at all
> (it used to be a no-op, but yielding gives better performance).
>
> -- PMM

[-- Attachment #2: Type: text/html, Size: 3341 bytes --]

  reply	other threads:[~2015-04-23 10:39 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 [this message]
2015-04-23 10:57         ` Peter Maydell
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=CAJy5ezqzHVwgHfmkxSDk4yDZb-6zoiU-cxeBNkUWSAF8Xj4GjQ@mail.gmail.com \
    --to=edgar.iglesias@gmail.com \
    --cc=alex.bennee@linaro.org \
    --cc=greg.bellows@linaro.org \
    --cc=peter.maydell@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 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.