From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Neuling <mikey@neuling.org>
Cc: linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
Gustavo Romero <gromero@linux.ibm.com>
Subject: Re: [PATCH] KVM: PPC: Book3S HV: Treat unrecognized TM instructions as illegal
Date: Mon, 17 Feb 2020 07:37:43 +0000 [thread overview]
Message-ID: <20200217073743.GT22482@gate.crashing.org> (raw)
In-Reply-To: <1752a0c735a455c5d3ca09209f5a52748c8f7116.camel@neuling.org>
On Mon, Feb 17, 2020 at 05:23:07PM +1100, Michael Neuling wrote:
> > > Hence, we should NOP this, not generate an illegal.
> >
> > It is not a reserved bit.
> >
> > The IMC entry for it matches op1\x011111 op2=1////01110 presumably, which
> > catches all TM instructions and nothing else (bits 0..5 and bits 21..30).
> > That does not look at bit 31, the softpatch handler has to deal with this.
> >
> > Some TM insns have bit 31 as 1 and some have it as /. All instructions
> > with a "." in the mnemonic have bit 31 is 1, all other have it reserved.
> > The tables in appendices D, E, F show tend. and tsr. as having it
> > reserved, which contradicts the individual instruction description (and
> > does not make much sense). (Only tcheck has /, everything else has 1;
> > everything else has a mnemonic with a dot, and does write CR0 always).
>
> Wow, interesting.
>
> P8 seems to be treating 31 as a reserved bit (with the table definition rather
> than the individual instruction description). I'm inclined to match P8 even
> though it's inconsistent with the dot mnemonic as you say.
"The POWER8 core ignores the state of reserved bits in the instructions
(denoted by “///” in the instruction definition) and executes the
instruction normally. Software should set these bits to ‘0’ per the
Power ISA." (p8 UM, 3.1.1.3; same in the p9 UM).
Segher
WARNING: multiple messages have this Message-ID (diff)
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Neuling <mikey@neuling.org>
Cc: linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
Gustavo Romero <gromero@linux.ibm.com>
Subject: Re: [PATCH] KVM: PPC: Book3S HV: Treat unrecognized TM instructions as illegal
Date: Mon, 17 Feb 2020 01:37:43 -0600 [thread overview]
Message-ID: <20200217073743.GT22482@gate.crashing.org> (raw)
In-Reply-To: <1752a0c735a455c5d3ca09209f5a52748c8f7116.camel@neuling.org>
On Mon, Feb 17, 2020 at 05:23:07PM +1100, Michael Neuling wrote:
> > > Hence, we should NOP this, not generate an illegal.
> >
> > It is not a reserved bit.
> >
> > The IMC entry for it matches op1=011111 op2=1////01110 presumably, which
> > catches all TM instructions and nothing else (bits 0..5 and bits 21..30).
> > That does not look at bit 31, the softpatch handler has to deal with this.
> >
> > Some TM insns have bit 31 as 1 and some have it as /. All instructions
> > with a "." in the mnemonic have bit 31 is 1, all other have it reserved.
> > The tables in appendices D, E, F show tend. and tsr. as having it
> > reserved, which contradicts the individual instruction description (and
> > does not make much sense). (Only tcheck has /, everything else has 1;
> > everything else has a mnemonic with a dot, and does write CR0 always).
>
> Wow, interesting.
>
> P8 seems to be treating 31 as a reserved bit (with the table definition rather
> than the individual instruction description). I'm inclined to match P8 even
> though it's inconsistent with the dot mnemonic as you say.
"The POWER8 core ignores the state of reserved bits in the instructions
(denoted by “///” in the instruction definition) and executes the
instruction normally. Software should set these bits to ‘0’ per the
Power ISA." (p8 UM, 3.1.1.3; same in the p9 UM).
Segher
next prev parent reply other threads:[~2020-02-17 7:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-13 15:15 [PATCH] KVM: PPC: Book3S HV: Treat unrecognized TM instructions as illegal Gustavo Romero
2020-02-13 15:15 ` Gustavo Romero
2020-02-13 23:31 ` Segher Boessenkool
2020-02-13 23:31 ` Segher Boessenkool
2020-02-13 23:49 ` Gustavo Romero
2020-02-13 23:49 ` Gustavo Romero
2020-02-17 1:07 ` Michael Neuling
2020-02-17 1:07 ` Michael Neuling
2020-02-17 5:57 ` Segher Boessenkool
2020-02-17 5:57 ` Segher Boessenkool
2020-02-17 6:23 ` Michael Neuling
2020-02-17 6:23 ` Michael Neuling
2020-02-17 7:37 ` Segher Boessenkool [this message]
2020-02-17 7:37 ` Segher Boessenkool
2020-02-18 21:23 ` Gustavo Romero
2020-02-18 21:23 ` Gustavo Romero
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=20200217073743.GT22482@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=gromero@linux.ibm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mikey@neuling.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.