Messages in this thread | | | Subject | Re: [PATCH v2 0/6] arm64: provide pseudo NMI with GICv3 | From | Marc Zyngier <> | Date | Wed, 2 May 2018 12:08:55 +0100 |
| |
On 01/05/18 21:51, Joel Fernandes wrote: > 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
It would mean teaching Group-0 interrupts to the arm64 kernel. Not an impossible task, but that'd be catering for a minority of broken systems. In my book, that's at the absolute bottom of the priority range (pun intended...).
M. -- Jazz is not dead. It just smells funny...
| |