On Mon, Apr 30, 2018 at 2:46 AM Julien Thierry <julien.thie...@arm.com> wrote: [...] > > On Wed, Jan 17, 2018 at 3:54 AM, Julien Thierry <julien.thie...@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
