Message ID | 20240306035721.2333531-1-ruanjinjie@huawei.com (mailing list archive) |
---|---|
Headers | show |
Series | target/arm: Implement FEAT_NMI and FEAT_GICv3_NMI | expand |
On 3/5/24 17:56, Jinjie Ruan via wrote: > This patch set implements FEAT_NMI and FEAT_GICv3_NMI for armv8. These > introduce support for a new category of interrupts in the architecture > which we can use to provide NMI like functionality. > > There are two modes for using this FEAT_NMI. When PSTATE.ALLINT or > PSTATE.SP & SCTLR_ELx.SCTLR_SPINTMASK is set, any entry to ELx causes all > interrupts including those with superpriority to be masked on entry to ELn > until the mask is explicitly removed by software or hardware. PSTATE.ALLINT > can be managed by software using the new register control ALLINT.ALLINT. > Independent controls are provided for this feature at each EL, usage at EL1 > should not disrupt EL2 or EL3. > > I have tested it with the following linux patches which try to support > FEAT_NMI in linux kernel: > > https://lore.kernel.org/linux-arm-kernel/Y4sH5qX5bK9xfEBp@lpieralisi/T/#mb4ba4a2c045bf72c10c2202c1dd1b82d3240dc88 > > In the test, SGI, PPI and SPI interrupts can all be set to have super priority > to be converted to a hardware NMI interrupt. The SGI is tested with kernel > IPI as NMI framework, softlockup, hardlockup and kgdb test cases, and the PPI > interrupt is tested with "perf top" command with hardware NMI enabled, and > the SPI interrupt is tested with a custom test module, in which NMI interrupts > can be received and sent normally. As far as I can see, this patch set is good to go. I'm fairly confident of the CPU side of the equation, but the GIC could use a second set of eyes. r~
Ping. On 2024/3/6 12:22, Richard Henderson wrote: > On 3/5/24 17:56, Jinjie Ruan via wrote: >> This patch set implements FEAT_NMI and FEAT_GICv3_NMI for armv8. These >> introduce support for a new category of interrupts in the architecture >> which we can use to provide NMI like functionality. >> >> There are two modes for using this FEAT_NMI. When PSTATE.ALLINT or >> PSTATE.SP & SCTLR_ELx.SCTLR_SPINTMASK is set, any entry to ELx causes all >> interrupts including those with superpriority to be masked on entry to >> ELn >> until the mask is explicitly removed by software or hardware. >> PSTATE.ALLINT >> can be managed by software using the new register control ALLINT.ALLINT. >> Independent controls are provided for this feature at each EL, usage >> at EL1 >> should not disrupt EL2 or EL3. >> >> I have tested it with the following linux patches which try to support >> FEAT_NMI in linux kernel: >> >> https://lore.kernel.org/linux-arm-kernel/Y4sH5qX5bK9xfEBp@lpieralisi/T/#mb4ba4a2c045bf72c10c2202c1dd1b82d3240dc88 >> >> In the test, SGI, PPI and SPI interrupts can all be set to have super >> priority >> to be converted to a hardware NMI interrupt. The SGI is tested with >> kernel >> IPI as NMI framework, softlockup, hardlockup and kgdb test cases, and >> the PPI >> interrupt is tested with "perf top" command with hardware NMI enabled, >> and >> the SPI interrupt is tested with a custom test module, in which NMI >> interrupts >> can be received and sent normally. > > As far as I can see, this patch set is good to go. I'm fairly confident > of the CPU side of the equation, but the GIC could use a second set of > eyes. > > > r~
On Mon, 11 Mar 2024 at 04:00, Jinjie Ruan <ruanjinjie@huawei.com> wrote: > > Ping. Hi; this is on my list to look at, but since it's not going into 9.0 I'm afraid I'm prioritising things for softfreeze/freeze period ahead of it. I promise I'll get to it before we unfreeze for 9.1, though :-) thanks -- PMM