All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: richard.henderson@linaro.org, qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH] target/ppc: Implement ISA v3.1 wait variants
Date: Mon, 24 May 2021 14:49:16 +1000	[thread overview]
Message-ID: <YKswTHP6Yrop3joJ@yekko> (raw)
In-Reply-To: <1621234864.zkbj7ifbxd.astroid@bobo.none>

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

On Mon, May 17, 2021 at 05:19:06PM +1000, Nicholas Piggin wrote:
> Excerpts from David Gibson's message of May 17, 2021 3:39 pm:
> > On Mon, May 17, 2021 at 12:46:51PM +1000, Nicholas Piggin wrote:
> >> ISA v3.1 adds new variations of wait, specified by the WC field. These
> >> are not compatible with the wait 0 implementation, because they add
> >> additional conditions that cause the processor to resume, which can
> >> cause software to hang or run very slowly.
> >> 
> >> Add the new wait variants with a trivial no-op implementation, which is
> >> allowed, as explained in comments: software must not depend on any
> >> particular architected WC condition having caused resumption of
> >> execution, therefore a no-op implementation is architecturally correct.
> >> 
> >> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > 
> > Logic looks fine.  There is no test on the CPU's features or model
> > here, though, so this will change behaviour for pre-3.1 CPUs as well.
> 
> Huh. 2.06-2.07 has very similar WC bits as 3.1, but 3.0 removed them
> and made them reserved. I should have looked back but I'd assumed
> they weren't there either.
> 
> Existing code treats WC != 0 as invalid on pre-3.0 processors AFAIKS,
> so that's not quite right for 2.06-7 (they should look more like 3.1).
> 
> But before that it looks like it was just wait with no WC field.
> 
> > What would invoking these wait variants (presumably reserved) on
> > earlier CPUs do?
> 
> Prior to 2.06, it looks like there is no WC field, and so they should 
> generate a program check. So that just leaves the incorrect program
> checks for 2.06-7, something like this should do it:
> 
> -GEN_HANDLER_E(wait, 0x1F, 0x1E, 0x00, 0x039FF801, PPC_NONE, PPC2_ISA300),
> +GEN_HANDLER_E(wait, 0x1F, 0x1E, 0x00, 0x039FF801, PPC_NONE, PPC2_ISA206),

Ok, can you update with such a change, and put some of this
explanation of the history in a comment.

> 2.06-3.1 should all be fine with this patch, AFAIKS they all have words 
> to the effect that WC != 0 is subject to implementation defined 
> behaviour and may be treated as a no-op or not implemented.

Ok.  Note that we do try to match specific CPU behaviour, not just the
architecture, although the architecture is obviously more important.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2021-05-24  4:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17  2:46 [PATCH] target/ppc: Implement ISA v3.1 wait variants Nicholas Piggin
2021-05-17  5:39 ` David Gibson
2021-05-17  7:19   ` Nicholas Piggin
2021-05-24  4:49     ` David Gibson [this message]

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=YKswTHP6Yrop3joJ@yekko \
    --to=david@gibson.dropbear.id.au \
    --cc=npiggin@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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 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.