From: Joel Fernandes <joelaf@google.com> To: julien.thierry@arm.com Cc: "Joel Fernandes (Google)" <joel.opensrc@gmail.com>, "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" <linux-arm-kernel@lists.infradead.org>, LKML <linux-kernel@vger.kernel.org>, Mark Rutland <mark.rutland@arm.com>, Marc Zyngier <marc.zyngier@arm.com>, James Morse <james.morse@arm.com>, Daniel Thompson <daniel.thompson@linaro.org> Subject: Re: [PATCH v2 0/6] arm64: provide pseudo NMI with GICv3 Date: Tue, 01 May 2018 20:51:45 +0000 [thread overview] Message-ID: <CAJWu+orJPfY4OMbNa5BqgteyYL+-r2vj+5O_ohbHe5_F-7TWTg@mail.gmail.com> (raw) In-Reply-To: <cc4347d0-995d-6921-a796-374a214cdce9@arm.com> On Mon, Apr 30, 2018 at 2:46 AM Julien Thierry <julien.thierry@arm.com> wrote: [...] > > On Wed, Jan 17, 2018 at 3:54 AM, Julien Thierry <julien.thierry@arm.com> wrote: > >> Hi, > >> > >> This series is a continuation of the work started by Daniel [1]. The goal > >> is to use GICv3 interrupt priorities to simulate an NMI. > >> > >> To achieve this, set two priorities, one for standard interrupts and > >> another, higher priority, for NMIs. Whenever we want to disable interrupts, > >> we mask the standard priority instead so NMIs can still be raised. Some > >> corner cases though still require to actually mask all interrupts > >> effectively disabling the NMI. > >> > >> Of course, using priority masking instead of PSR.I comes at some cost. On > >> hackbench, the drop of performance seems to be >1% on average for this > >> version. I can only attribute that to recent changes in the kernel as > > > > Do you have more specific performance data on the performance overhead > > with this series? > > > Not at the moment. I was planning on doing a v3 anyway considering this > series is getting a bit old and the GICv3 driver has had some modifications. Great! Looking forward to it, will try to find some time to review this set as well. > Once I get to it I can try to have more detailed performance data on a > recent kernel. I've really only measured the performance on hackbench > and on kernel build from defconfig (and for the kernel build the > performance difference was completely hidden by the noise). > >> hackbench seems slightly slower compared to my other benchmarks while the > >> runs with the use of GICv3 priorities have stayed in the same time frames. > >> KVM Guests do not seem to be affected preformance-wise by the host using > >> PMR to mask interrupts or not. > >> > >> Currently, only PPIs and SPIs can be set as NMIs. IPIs being currently > >> hardcoded IRQ numbers, there isn't a generic interface to set SGIs as NMI > >> for now. I don't think there is any reason LPIs should be allowed to be set > >> as NMI as they do not have an active state. > >> When an NMI is active on a CPU, no other NMI can be triggered on the CPU. > >> > >> > >> Requirements to use this: > >> - Have GICv3 > >> - SCR_EL3.FIQ is set to 1 when linux runs > > > > Ah I see it mentioned here. Again, can you clarify if this is > > something that can be misconfigured? Is it something that the > > bootloader sets? > > > Yes, this is something that the bootloader sets and we have seen a few > cases where it is set to 0, so it can be "misconfigured". > It is not impossible to handle this case, but this bit affects the view > the GICv3 CPU interface has on interrupt priority values. However it > requires to add some conditions in both the interrupt handling and > masking/unmasking code, so ideally we would avoid adding things to this. > But the idea is that Linux only deals with group 1 interrupts, and group > 1 interrupts are only signaled as FIQs when the execution state is > secure or at EL3, which should never happen in Linux's case. So ideally > we'd like firmwares to set up this bit properly rather than to have to > deal with both cases when only one of them makes sense for Linux. From what I see, on all our platforms, FIQs are delivered to the secure monitor only. Which is the reason for this patchset in the first place. I can't imagine a usecase that is not designed like this (and have not come across this), so its probably Ok to just assume SCR_EL3.FIQ is to 1. In the future, if SCR_EL3.FIQ is set 0, then the NMI should use the FIQ mechanism delivered to the non-secure OS. Does what I say make sense or was I just shooting arrows in the dark? :-P thanks, - Joel
WARNING: multiple messages have this Message-ID (diff)
From: joelaf@google.com (Joel Fernandes) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 0/6] arm64: provide pseudo NMI with GICv3 Date: Tue, 01 May 2018 20:51:45 +0000 [thread overview] Message-ID: <CAJWu+orJPfY4OMbNa5BqgteyYL+-r2vj+5O_ohbHe5_F-7TWTg@mail.gmail.com> (raw) In-Reply-To: <cc4347d0-995d-6921-a796-374a214cdce9@arm.com> On Mon, Apr 30, 2018 at 2:46 AM Julien Thierry <julien.thierry@arm.com> wrote: [...] > > On Wed, Jan 17, 2018 at 3:54 AM, Julien Thierry <julien.thierry@arm.com> wrote: > >> Hi, > >> > >> This series is a continuation of the work started by Daniel [1]. The goal > >> is to use GICv3 interrupt priorities to simulate an NMI. > >> > >> To achieve this, set two priorities, one for standard interrupts and > >> another, higher priority, for NMIs. Whenever we want to disable interrupts, > >> we mask the standard priority instead so NMIs can still be raised. Some > >> corner cases though still require to actually mask all interrupts > >> effectively disabling the NMI. > >> > >> Of course, using priority masking instead of PSR.I comes at some cost. On > >> hackbench, the drop of performance seems to be >1% on average for this > >> version. I can only attribute that to recent changes in the kernel as > > > > Do you have more specific performance data on the performance overhead > > with this series? > > > Not at the moment. I was planning on doing a v3 anyway considering this > series is getting a bit old and the GICv3 driver has had some modifications. Great! Looking forward to it, will try to find some time to review this set as well. > Once I get to it I can try to have more detailed performance data on a > recent kernel. I've really only measured the performance on hackbench > and on kernel build from defconfig (and for the kernel build the > performance difference was completely hidden by the noise). > >> hackbench seems slightly slower compared to my other benchmarks while the > >> runs with the use of GICv3 priorities have stayed in the same time frames. > >> KVM Guests do not seem to be affected preformance-wise by the host using > >> PMR to mask interrupts or not. > >> > >> Currently, only PPIs and SPIs can be set as NMIs. IPIs being currently > >> hardcoded IRQ numbers, there isn't a generic interface to set SGIs as NMI > >> for now. I don't think there is any reason LPIs should be allowed to be set > >> as NMI as they do not have an active state. > >> When an NMI is active on a CPU, no other NMI can be triggered on the CPU. > >> > >> > >> Requirements to use this: > >> - Have GICv3 > >> - SCR_EL3.FIQ is set to 1 when linux runs > > > > Ah I see it mentioned here. Again, can you clarify if this is > > something that can be misconfigured? Is it something that the > > bootloader sets? > > > Yes, this is something that the bootloader sets and we have seen a few > cases where it is set to 0, so it can be "misconfigured". > It is not impossible to handle this case, but this bit affects the view > the GICv3 CPU interface has on interrupt priority values. However it > requires to add some conditions in both the interrupt handling and > masking/unmasking code, so ideally we would avoid adding things to this. > But the idea is that Linux only deals with group 1 interrupts, and group > 1 interrupts are only signaled as FIQs when the execution state is > secure or at EL3, which should never happen in Linux's case. So ideally > we'd like firmwares to set up this bit properly rather than to have to > deal with both cases when only one of them makes sense for Linux. From what I see, on all our platforms, FIQs are delivered to the secure monitor only. Which is the reason for this patchset in the first place. I can't imagine a usecase that is not designed like this (and have not come across this), so its probably Ok to just assume SCR_EL3.FIQ is to 1. In the future, if SCR_EL3.FIQ is set 0, then the NMI should use the FIQ mechanism delivered to the non-secure OS. Does what I say make sense or was I just shooting arrows in the dark? :-P thanks, - Joel
next prev parent reply other threads:[~2018-05-01 20:51 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-17 11:54 [PATCH v2 0/6] arm64: provide pseudo NMI with GICv3 Julien Thierry 2018-01-17 11:54 ` Julien Thierry 2018-01-17 11:54 ` [PATCH v2 1/6] arm64: cpufeature: Allow early detect of specific features Julien Thierry 2018-01-17 11:54 ` Julien Thierry 2018-01-22 12:05 ` Suzuki K Poulose 2018-01-22 12:05 ` Suzuki K Poulose 2018-01-22 12:21 ` Julien Thierry 2018-01-22 12:21 ` Julien Thierry 2018-01-22 13:38 ` Daniel Thompson 2018-01-22 13:38 ` Daniel Thompson 2018-01-22 13:57 ` Marc Zyngier 2018-01-22 13:57 ` Marc Zyngier 2018-01-22 14:14 ` Julien Thierry 2018-01-22 14:14 ` Julien Thierry 2018-01-22 14:20 ` Marc Zyngier 2018-01-22 14:20 ` Marc Zyngier 2018-01-22 14:45 ` Suzuki K Poulose 2018-01-22 14:45 ` Suzuki K Poulose 2018-01-22 15:01 ` Julien Thierry 2018-01-22 15:01 ` Julien Thierry 2018-01-22 15:13 ` Suzuki K Poulose 2018-01-22 15:13 ` Suzuki K Poulose 2018-01-22 15:23 ` Julien Thierry 2018-01-22 15:23 ` Julien Thierry 2018-01-22 15:34 ` Suzuki K Poulose 2018-01-22 15:34 ` Suzuki K Poulose 2018-01-17 11:54 ` [PATCH v2 2/6] arm64: alternative: Apply alternatives early in boot process Julien Thierry 2018-01-17 11:54 ` Julien Thierry 2018-05-04 10:06 ` Julien Thierry 2018-05-04 10:06 ` Julien Thierry 2018-05-09 14:27 ` Daniel Thompson 2018-05-09 14:27 ` Daniel Thompson 2018-05-09 21:52 ` Suzuki K Poulose 2018-05-09 21:52 ` Suzuki K Poulose 2018-05-11 8:12 ` Julien Thierry 2018-05-11 8:12 ` Julien Thierry 2018-05-11 9:19 ` Suzuki K Poulose 2018-05-11 9:19 ` Suzuki K Poulose 2018-01-17 11:54 ` [PATCH v2 3/6] arm64: irqflags: Use ICC sysregs to implement IRQ masking Julien Thierry 2018-01-17 11:54 ` Julien Thierry 2018-01-17 11:54 ` [PATCH v2 4/6] irqchip/gic: Add functions to access irq priorities Julien Thierry 2018-01-17 11:54 ` Julien Thierry 2018-01-17 11:54 ` [PATCH v2 5/6] arm64: Detect current view of GIC priorities Julien Thierry 2018-01-17 11:54 ` Julien Thierry 2018-02-03 3:01 ` Yang Yingliang 2018-02-03 3:01 ` Yang Yingliang 2018-01-17 11:54 ` [PATCH v2 6/6] arm64: Add support for pseudo-NMIs Julien Thierry 2018-01-17 11:54 ` Julien Thierry 2018-01-17 12:10 ` [PATCH v2 0/6] arm64: provide pseudo NMI with GICv3 Julien Thierry 2018-01-17 12:10 ` Julien Thierry 2018-04-29 6:37 ` Joel Fernandes 2018-04-29 6:37 ` Joel Fernandes 2018-04-30 9:53 ` Julien Thierry 2018-04-30 9:53 ` Julien Thierry 2018-04-30 10:55 ` Daniel Thompson 2018-04-30 10:55 ` Daniel Thompson 2018-05-01 18:18 ` Joel Fernandes 2018-05-01 18:18 ` Joel Fernandes 2018-05-02 11:02 ` Daniel Thompson 2018-05-02 11:02 ` Daniel Thompson [not found] ` <8315db11-7899-008d-f37a-c311b278a1c4@hisilicon.com> [not found] ` <7ec201a4-e2dc-8a1e-e8a1-f2b10bd41cd4@huawei.com> [not found] ` <afb46ee0-4f26-fd1a-2fd1-866dc0b25175@arm.com> 2018-03-27 12:48 ` dongbo (E) 2018-03-27 13:02 ` Marc Zyngier 2018-03-27 13:09 ` Julien Thierry 2018-04-29 6:35 ` Joel Fernandes 2018-04-29 6:35 ` Joel Fernandes 2018-04-30 9:46 ` Julien Thierry 2018-04-30 9:46 ` Julien Thierry 2018-05-01 20:51 ` Joel Fernandes [this message] 2018-05-01 20:51 ` Joel Fernandes 2018-05-02 11:08 ` Marc Zyngier 2018-05-02 11:08 ` Marc Zyngier
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=CAJWu+orJPfY4OMbNa5BqgteyYL+-r2vj+5O_ohbHe5_F-7TWTg@mail.gmail.com \ --to=joelaf@google.com \ --cc=daniel.thompson@linaro.org \ --cc=james.morse@arm.com \ --cc=joel.opensrc@gmail.com \ --cc=julien.thierry@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marc.zyngier@arm.com \ --cc=mark.rutland@arm.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: 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.