From: Michael Ellerman <mpe@ellerman.id.au> To: Shawn Landden <shawn@git.icu>, linuxppc-dev@lists.ozlabs.org Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, linux-kernel@vger.kernel.org, Shawn Landden <shawn@git.icu> Subject: Re: [PATCH RESEND] powerpc: add simd.h implementation specific to PowerPC Date: Mon, 13 May 2019 21:53:09 +1000 [thread overview] Message-ID: <87mujqtvtm.fsf@concordia.ellerman.id.au> (raw) In-Reply-To: <20190513005104.20140-1-shawn@git.icu> Shawn Landden <shawn@git.icu> writes: > It is safe to do SIMD in an interrupt on PowerPC. No it's not sorry :) > Only disable when there is no SIMD available > (and this is a static branch). > > Tested and works with the WireGuard (Zinc) patch I wrote that needs this. > Also improves performance of the crypto subsystem that checks this. > > Re-sending because this linuxppc-dev didn't seem to accept it. It did but you were probably moderated as a non-subscriber? In future if you just wait a while for the moderators to wake up it should come through. Though having posted once and been approved I think you might not get moderated at all in future (?). > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203571 > Signed-off-by: Shawn Landden <shawn@git.icu> > --- > arch/powerpc/include/asm/simd.h | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > create mode 100644 arch/powerpc/include/asm/simd.h > > diff --git a/arch/powerpc/include/asm/simd.h b/arch/powerpc/include/asm/simd.h > new file mode 100644 > index 000000000..b3fecb95a > --- /dev/null > +++ b/arch/powerpc/include/asm/simd.h > @@ -0,0 +1,15 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > + > +#include <asm/cpu_has_feature.h> > + > +/* > + * may_use_simd - whether it is allowable at this time to issue SIMD > + * instructions or access the SIMD register file > + * > + * As documented in Chapter 6.2.1 Machine Status Save/Restore Registers > + * of Power ISA (2.07 and 3.0), all registers are saved/restored in an interrupt. I think the confusion here is that the ISA says: When various interrupts occur, the state of the machine is saved in the Machine Status Save/Restore registers (SRR0 and SRR1). And you've read that to mean all "the state" of the machine, ie. including GPRs, FPRs etc. But unfortunately it's not that simple. All the hardware does is write two 64-bit registers (SRR0 & SRR1) with the information required to be able to return to the state the CPU was in prior to the interrupt. That includes (obviously) the PC you were executing at, and what state the CPU was in (ie. 64/32-bit, MMU on/off, FP on/off etc.). All the saving of registers etc. is left up to software. It's the RISC way :) I guess we need to work out why exactly may_use_simd() is returning false in your kworker. cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au> To: Shawn Landden <shawn@git.icu>, linuxppc-dev@lists.ozlabs.org Cc: Shawn Landden <shawn@git.icu>, Paul Mackerras <paulus@samba.org>, linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND] powerpc: add simd.h implementation specific to PowerPC Date: Mon, 13 May 2019 21:53:09 +1000 [thread overview] Message-ID: <87mujqtvtm.fsf@concordia.ellerman.id.au> (raw) In-Reply-To: <20190513005104.20140-1-shawn@git.icu> Shawn Landden <shawn@git.icu> writes: > It is safe to do SIMD in an interrupt on PowerPC. No it's not sorry :) > Only disable when there is no SIMD available > (and this is a static branch). > > Tested and works with the WireGuard (Zinc) patch I wrote that needs this. > Also improves performance of the crypto subsystem that checks this. > > Re-sending because this linuxppc-dev didn't seem to accept it. It did but you were probably moderated as a non-subscriber? In future if you just wait a while for the moderators to wake up it should come through. Though having posted once and been approved I think you might not get moderated at all in future (?). > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203571 > Signed-off-by: Shawn Landden <shawn@git.icu> > --- > arch/powerpc/include/asm/simd.h | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > create mode 100644 arch/powerpc/include/asm/simd.h > > diff --git a/arch/powerpc/include/asm/simd.h b/arch/powerpc/include/asm/simd.h > new file mode 100644 > index 000000000..b3fecb95a > --- /dev/null > +++ b/arch/powerpc/include/asm/simd.h > @@ -0,0 +1,15 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > + > +#include <asm/cpu_has_feature.h> > + > +/* > + * may_use_simd - whether it is allowable at this time to issue SIMD > + * instructions or access the SIMD register file > + * > + * As documented in Chapter 6.2.1 Machine Status Save/Restore Registers > + * of Power ISA (2.07 and 3.0), all registers are saved/restored in an interrupt. I think the confusion here is that the ISA says: When various interrupts occur, the state of the machine is saved in the Machine Status Save/Restore registers (SRR0 and SRR1). And you've read that to mean all "the state" of the machine, ie. including GPRs, FPRs etc. But unfortunately it's not that simple. All the hardware does is write two 64-bit registers (SRR0 & SRR1) with the information required to be able to return to the state the CPU was in prior to the interrupt. That includes (obviously) the PC you were executing at, and what state the CPU was in (ie. 64/32-bit, MMU on/off, FP on/off etc.). All the saving of registers etc. is left up to software. It's the RISC way :) I guess we need to work out why exactly may_use_simd() is returning false in your kworker. cheers
next prev parent reply other threads:[~2019-05-13 11:53 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-12 16:50 [PATCH] powerpc: add simd.h implementation specific to PowerPC Shawn Landden 2019-05-12 16:50 ` Shawn Landden 2019-05-13 0:51 ` [PATCH RESEND] " Shawn Landden 2019-05-13 0:51 ` Shawn Landden 2019-05-13 11:53 ` Michael Ellerman [this message] 2019-05-13 11:53 ` Michael Ellerman 2019-05-14 1:44 ` [PATCH 1/2] [PowerPC] Add simd.h implementation Shawn Landden 2019-05-14 1:44 ` [PATCH 2/2] [PowerPC] Allow use of SIMD in interrupts from kernel code Shawn Landden 2019-05-14 5:43 ` [PATCH 1/2] [PowerPC] Add simd.h implementation Benjamin Herrenschmidt 2019-05-14 15:44 ` Shawn Landden 2019-05-14 15:46 ` [v3 " Shawn Landden 2019-05-14 15:46 ` [v3 2/2] [PowerPC] Allow use of SIMD in interrupts from kernel code Shawn Landden 2019-05-15 1:03 ` kbuild test robot 2019-05-14 2:23 ` [v2 1/2] [PowerPC] Add simd.h implementation Shawn Landden 2019-05-14 2:23 ` [v2 2/2] [PowerPC] Allow use of SIMD in interrupts from kernel code Shawn Landden 2019-05-14 7:22 ` Russell Currey 2019-05-14 15:35 ` Shawn Landden 2019-05-14 12:49 ` [PATCH] powerpc: Allow may_use_simd() to function as feature detection Shawn Landden 2019-05-14 18:06 ` Segher Boessenkool 2019-05-14 19:00 ` Shawn Landden 2019-05-15 1:36 ` [PATCH 1/2] [PowerPC] Add simd.h implementation Shawn Landden 2019-05-15 1:37 ` [v4 PATCH " Shawn Landden 2019-05-15 1:37 ` [v4 PATCH 2/2] [PowerPC] Allow use of SIMD in interrupts from kernel code Shawn Landden 2019-05-15 6:27 ` [v4 PATCH 1/2] [PowerPC] Add simd.h implementation Christophe Leroy 2019-05-16 1:12 ` Shawn Landden 2019-05-18 16:04 ` [RESEND v4 " Shawn Landden 2019-05-18 16:04 ` [RESEND v4 PATCH 2/2] [PowerPC] Allow use of SIMD in interrupts from kernel code Shawn Landden
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=87mujqtvtm.fsf@concordia.ellerman.id.au \ --to=mpe@ellerman.id.au \ --cc=benh@kernel.crashing.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=paulus@samba.org \ --cc=shawn@git.icu \ /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: linkBe 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.