Re: [RFC PATCH v7 00/23] target/arm: Implement FEAT_NMI and FEAT_GICv3_NMI

[Jinjie Ruan]

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~