Re: [PATCH v13 00/24] target/arm: Implement FEAT_NMI and FEAT_GICv3_NMI
On 2024/4/19 21:41, Peter Maydell wrote:
> On Sun, 7 Apr 2024 at 09:19, Jinjie Ruan 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.
>
> I had one last loose end I wanted to tidy up, and I got round
> to working through reading the spec about it today. This is
> the question of what the "is NMI enabled?" test should be
> in the code in arm_gicv3_cpuif.c.
>
> The spec wording isn't always super clear, but there are several
> things here:
>
> * FEAT_NMI : the changes to the CPU proper which implement
>superpriority for IRQ and FIQ, PSTATE.ALLINT, etc etc.
> * FEAT_GICv3_NMI : the changes to the CPU interface for
>GICv3 NMI handling. Any CPU with FEAT_NMI and FEAT_GICv3
>must have this.
> * NMI support in the IRI (Interrupt Routing Infrastructure,
>i.e. all the bits of the GIC that aren't the cpuif; the
>distributor and redistributors). Table 3-1 in the GIC spec
>says that you can have an IRI without NMI support connected
>to a CPU which does have NMI support. This is what the ID
>register bit GICD_TYPER.NMI reports.
That is right. It seems reasonable for me.
>
> At the moment this patchset conflates FEAT_GICv3_NMI and
> the NMI support in the IRI. The effect of this is that we
> allow a machine model to create a CPU with FEAT_NMI but
> without FEAT_GICv3_NMI in the cpuif, and we don't allow
> a setup where the CPU and cpuif have NMI support but the
> IRI does not. (This will actually happen with this patchset
> with the sbsa-ref machine and -cpu max, because we haven't
> (yet) made sbsa-ref enable NMI in the GIC device when the
> CPU has NMI support.)
>
> For a Linux guest this doesn't make much difference, because
> Linux will only enable NMI support if it finds it in both
> the IRI and the CPU, but I think it would be better to
> get the enable-tests right as these can be awkward to change
> after the fact in a backwards-compatible way.
>
> I think this is easy to fix -- we can add a new bool field
> GICv3CPUState::nmi_support which we initialize in
> gicv3_init_cpuif() if the CPU has FEAT_NMI, and make the
> checks in arm_gicv3_cpuif.c check cs->nmi_support instead
> of cs->gic->nmi_support. That looks like this squashed into
> patch 18:
>
> diff --git a/include/hw/intc/arm_gicv3_common.h
> b/include/hw/intc/arm_gicv3_common.h
> index 88533749ebb..cd09bee3bc4 100644
> --- a/include/hw/intc/arm_gicv3_common.h
> +++ b/include/hw/intc/arm_gicv3_common.h
> @@ -225,6 +225,13 @@ struct GICv3CPUState {
>
> /* This is temporary working state, to avoid a malloc in gicv3_update()
> */
> bool seenbetter;
> +
> +/*
> + * Whether the CPU interface has NMI support (FEAT_GICv3_NMI). The
> + * CPU interface may support NMIs even when the GIC proper (what the
> + * spec calls the IRI; the redistributors and distributor) does not.
> + */
> +bool nmi_support;
> };
>
> /*
> diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c
> index 2457b7bca23..715909d0f7d 100644
> --- a/hw/intc/arm_gicv3_cpuif.c
> +++ b/hw/intc/arm_gicv3_cpuif.c
> @@ -21,6 +21,7 @@
> #include "hw/irq.h"
> #include "cpu.h"
> #include "target/arm/cpregs.h"
> +#include "target/arm/cpu-features.h"
> #include "sysemu/tcg.h"
> #include "sysemu/qtest.h"
>
> @@ -839,7 +840,7 @@ static int icc_highest_active_prio(GICv3CPUState *cs)
> */
> int i;
>
> -if (cs->gic->nmi_support) {
> +if (cs->nmi_support) {
> /*
> * If an NMI is active this takes precedence over anything else
> * for priority purposes; the NMI bit is only in the AP1R0 bit.
> @@ -1285,7 +1286,7 @@ static void icc_drop_prio(GICv3CPUState *cs, int grp)
> continue;
> }
>
> -if (i == 0 && cs->gic->nmi_support && (*papr & ICC_AP1R_EL1_NMI)) {
> +if (i == 0 && cs->nmi_support && (*papr & ICC_AP1R_EL1_NMI)) {
> *papr &= (~ICC_AP1R_EL1_NMI);
> break;
> }
> @@ -1324,7 +1325,7 @@ static int icc_highest_active_group(GICv3CPUState *cs)
> */
> int i;
>
> -if (cs->gic->nmi_support) {
> +if (cs->nmi_support) {
> if (cs->icc_apr[GICV3_G1][0] & ICC_AP1R_EL1_NMI) {
> return GICV3_G1;
> }
> @@ -1787,7 +1788,7 @@ static void icc_ap_write(CPUARMState *env, const
> ARMCPRegInfo *ri,
> return;
> }
>
> -if (cs->gic->nmi_support) {
> +if (cs->nmi_support) {
> cs->icc_apr[grp][regno] = value & (0xU | ICC_AP1R_EL1_NMI);
> } else {
> cs->icc_apr[grp][regno] = value & 0xU;
> @@ -1901,7 +1902,7 @@ static uint64_t icc_rpr_read(CPUARMState *env,
> const ARMCPRegInfo *ri)
> }
> }
>
> -if (cs->gic->nmi_support) {
> +if (cs->nmi_support) {
> /* NMI info is reported in the high bits of RPR */
> if
Re: [PATCH v13 00/24] target/arm: Implement FEAT_NMI and FEAT_GICv3_NMI
On Sun, 7 Apr 2024 at 09:19, Jinjie Ruan 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.
I had one last loose end I wanted to tidy up, and I got round
to working through reading the spec about it today. This is
the question of what the "is NMI enabled?" test should be
in the code in arm_gicv3_cpuif.c.
The spec wording isn't always super clear, but there are several
things here:
* FEAT_NMI : the changes to the CPU proper which implement
superpriority for IRQ and FIQ, PSTATE.ALLINT, etc etc.
* FEAT_GICv3_NMI : the changes to the CPU interface for
GICv3 NMI handling. Any CPU with FEAT_NMI and FEAT_GICv3
must have this.
* NMI support in the IRI (Interrupt Routing Infrastructure,
i.e. all the bits of the GIC that aren't the cpuif; the
distributor and redistributors). Table 3-1 in the GIC spec
says that you can have an IRI without NMI support connected
to a CPU which does have NMI support. This is what the ID
register bit GICD_TYPER.NMI reports.
At the moment this patchset conflates FEAT_GICv3_NMI and
the NMI support in the IRI. The effect of this is that we
allow a machine model to create a CPU with FEAT_NMI but
without FEAT_GICv3_NMI in the cpuif, and we don't allow
a setup where the CPU and cpuif have NMI support but the
IRI does not. (This will actually happen with this patchset
with the sbsa-ref machine and -cpu max, because we haven't
(yet) made sbsa-ref enable NMI in the GIC device when the
CPU has NMI support.)
For a Linux guest this doesn't make much difference, because
Linux will only enable NMI support if it finds it in both
the IRI and the CPU, but I think it would be better to
get the enable-tests right as these can be awkward to change
after the fact in a backwards-compatible way.
I think this is easy to fix -- we can add a new bool field
GICv3CPUState::nmi_support which we initialize in
gicv3_init_cpuif() if the CPU has FEAT_NMI, and make the
checks in arm_gicv3_cpuif.c check cs->nmi_support instead
of cs->gic->nmi_support. That looks like this squashed into
patch 18:
diff --git a/include/hw/intc/arm_gicv3_common.h
b/include/hw/intc/arm_gicv3_common.h
index 88533749ebb..cd09bee3bc4 100644
--- a/include/hw/intc/arm_gicv3_common.h
+++ b/include/hw/intc/arm_gicv3_common.h
@@ -225,6 +225,13 @@ struct GICv3CPUState {
/* This is temporary working state, to avoid a malloc in gicv3_update() */
bool seenbetter;
+
+/*
+ * Whether the CPU interface has NMI support (FEAT_GICv3_NMI). The
+ * CPU interface may support NMIs even when the GIC proper (what the
+ * spec calls the IRI; the redistributors and distributor) does not.
+ */
+bool nmi_support;
};
/*
diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c
index 2457b7bca23..715909d0f7d 100644
--- a/hw/intc/arm_gicv3_cpuif.c
+++ b/hw/intc/arm_gicv3_cpuif.c
@@ -21,6 +21,7 @@
#include "hw/irq.h"
#include "cpu.h"
#include "target/arm/cpregs.h"
+#include "target/arm/cpu-features.h"
#include "sysemu/tcg.h"
#include "sysemu/qtest.h"
@@ -839,7 +840,7 @@ static int icc_highest_active_prio(GICv3CPUState *cs)
*/
int i;
-if (cs->gic->nmi_support) {
+if (cs->nmi_support) {
/*
* If an NMI is active this takes precedence over anything else
* for priority purposes; the NMI bit is only in the AP1R0 bit.
@@ -1285,7 +1286,7 @@ static void icc_drop_prio(GICv3CPUState *cs, int grp)
continue;
}
-if (i == 0 && cs->gic->nmi_support && (*papr & ICC_AP1R_EL1_NMI)) {
+if (i == 0 && cs->nmi_support && (*papr & ICC_AP1R_EL1_NMI)) {
*papr &= (~ICC_AP1R_EL1_NMI);
break;
}
@@ -1324,7 +1325,7 @@ static int icc_highest_active_group(GICv3CPUState *cs)
*/
int i;
-if (cs->gic->nmi_support) {
+if (cs->nmi_support) {
if (cs->icc_apr[GICV3_G1][0] & ICC_AP1R_EL1_NMI) {
return GICV3_G1;
}
@@ -1787,7 +1788,7 @@ static void icc_ap_write(CPUARMState *env, const
ARMCPRegInfo *ri,
return;
}
-if (cs->gic->nmi_support) {
+if (cs->nmi_support) {
cs->icc_apr[grp][regno] = value & (0xU | ICC_AP1R_EL1_NMI);
} else {
cs->icc_apr[grp][regno] = value & 0xU;
@@ -1901,7 +1902,7 @@ static uint64_t icc_rpr_read(CPUARMState *env,
const ARMCPRegInfo *ri)
}
}
-if (cs->gic->nmi_support) {
+if (cs->nmi_support) {
/* NMI info is reported in the high bits of RPR */
if (arm_feature(env, ARM_FEATURE_EL3) && !arm_is_secure(env)) {
if (cs->icc_apr[GICV3_G1NS][0] & ICC_AP1R_EL1_NMI) {
@@ -2961,7 +2962,16 @@ void gicv3_init_cpuif(GICv3State *s)
*/
define_arm_cp_regs(cpu, gicv3_cpuif_reginfo);
-if (s->nmi_support) {
+/*
+ * If the CPU implements FEAT_NMI
Re: [PATCH v13 00/24] target/arm: Implement FEAT_NMI and FEAT_GICv3_NMI
On 2024/4/10 20:58, Peter Maydell wrote: > On Wed, 10 Apr 2024 at 07:19, Jinjie Ruan via wrote: >> >> Ping. > > As I said in my reply on the previous version, we're in > freeze at the moment, so this patchset is not going anywhere > until 9.0 releases. I think it's in shape to apply after that. Thank you! I don't know if there's any other minor issues. > > thanks > -- PMM
Re: [PATCH v13 00/24] target/arm: Implement FEAT_NMI and FEAT_GICv3_NMI
On Wed, 10 Apr 2024 at 07:19, Jinjie Ruan via wrote: > > Ping. As I said in my reply on the previous version, we're in freeze at the moment, so this patchset is not going anywhere until 9.0 releases. I think it's in shape to apply after that. thanks -- PMM
Re: [PATCH v13 00/24] target/arm: Implement FEAT_NMI and FEAT_GICv3_NMI
Ping. On 2024/4/7 16:17, Jinjie Ruan 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. > > And the Virtual NMI(VNMI) SGI, PPI and SPI interrupts has also been tested in > nested QEMU Virtual Machine with host "virtualization=true". The SGI VNMI is > tested by accessing GICR_INMIR0 and GICR_ISPENDR0 with devmem command, as well > as hardlockup and kgdb testcases. The PPI VNMI is tested by accessing > GICR_INMIR0 and GICR_ISPENDR0 with devmem command, as well as "perf top" > command with hardware NMI enabled, which works well. The SPI VNMI is tested > with a custom test module, in which SPI VNMI can be sent from the GIC and > received normally. > > +-+ > | Distributor | > +-+ > SPI | NMI| NMI > \/\/ > ++ +---+ > | Redist | | Redist| > ++ +---+ > SGI | NMI PPI | NMI > \/\/ > +-+ +---+ > |CPU Interface| ... | CPU Interface | > +-+ +---+ >| NMI | NMI > \/\/ > +-+ +-+ > | PE | | PE | > +-+ +-+ > > Changes in v13: > - Handle PSTATE.ALLINT the same way as PSTATE.DAIF in the illegal_return > exit path. > - Adjust "hw/arm/virt: Wire NMI and VINMI irq lines from GIC to CPU" to after > "hw/intc/arm_gicv3: Add external IRQ lines for NMI" to fix the unexpected > error with patchseries at this point. > - Only connect NMI irq lines from GIC to CPU if vms->gic_version is not > VIRT_GIC_VERSION_2 to fix the gic-version=2 unexpected error. > - Enforce RES0 bit in NMI field when FEAT_GICv3_NMI is not implemented for > ICH_LR_EL2. > - Swap the order of the "irq" and "prio" args in gicv3_get_priority() to make > input before output. > - Check tcg_enabled() for gicv3_nmi_present(). > - Update the comment for gicv3_nmi_present(). > - Update the commit message. > - Add Reviewed-by. > - Add Suggested-by. > > Changes in v12: > - pPriority<63> = ICC_AP1R_EL1NS<63> if HaveNMIExt() and HaveEL(EL3) and > (IsNonSecure(), fix the wrong writing. > - Do not check nmi_support repetitively in icc_hppi_can_preempt(), > and icc_activate_irq, ich_highest_active_virt_prio(), hppvi_index(), > icv_hppi_can_preempt(), icv_rpr_read() and icv_activate_irq(), > gicv3_cpuif_virt_irq_fiq_update(). > - Check hppi.nmi after check icc_hppi_can_preempt() for icc_iar1_read() and > icc_nmiar1_read(). > - When NMI is 1, the virtual interrupt's priority is 0x0. > - Make the thisnmi logic more concisely in hppvi_index(). > - Use is_nmi to simplify code and check is_nmi before comparing vpmr. > - Also check sctlrx.NMI in icv_iar_read(). > - Check icv_hppi_can_preempt() for icv_nmiar1_read(). > - Check ICH_LR_EL2.NMI after check icv_hppi_can_preempt() as icv_iar_read() > do it in icv_nmiar1_read(). > - Correct thisnmi to bool in icv_eoir_write(). > - Check thisnmi and nmi both true instead of identical in icv_eoir_write(). > - nmi_needed -> gicv3_cpu_nmi_needed, needed_nmi -> gicv3_nmi_needed. > - Correct the comment style in arm_cpu_initfn() and icv_nmiar1_read(). > - Fix the typo, "prioirty" -> "priority". >
[PATCH v13 00/24] target/arm: Implement FEAT_NMI and FEAT_GICv3_NMI
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. And the Virtual NMI(VNMI) SGI, PPI and SPI interrupts has also been tested in nested QEMU Virtual Machine with host "virtualization=true". The SGI VNMI is tested by accessing GICR_INMIR0 and GICR_ISPENDR0 with devmem command, as well as hardlockup and kgdb testcases. The PPI VNMI is tested by accessing GICR_INMIR0 and GICR_ISPENDR0 with devmem command, as well as "perf top" command with hardware NMI enabled, which works well. The SPI VNMI is tested with a custom test module, in which SPI VNMI can be sent from the GIC and received normally. +-+ | Distributor | +-+ SPI | NMI| NMI \/\/ ++ +---+ | Redist | | Redist| ++ +---+ SGI | NMI PPI | NMI \/\/ +-+ +---+ |CPU Interface| ... | CPU Interface | +-+ +---+ | NMI | NMI \/\/ +-+ +-+ | PE | | PE | +-+ +-+ Changes in v13: - Handle PSTATE.ALLINT the same way as PSTATE.DAIF in the illegal_return exit path. - Adjust "hw/arm/virt: Wire NMI and VINMI irq lines from GIC to CPU" to after "hw/intc/arm_gicv3: Add external IRQ lines for NMI" to fix the unexpected error with patchseries at this point. - Only connect NMI irq lines from GIC to CPU if vms->gic_version is not VIRT_GIC_VERSION_2 to fix the gic-version=2 unexpected error. - Enforce RES0 bit in NMI field when FEAT_GICv3_NMI is not implemented for ICH_LR_EL2. - Swap the order of the "irq" and "prio" args in gicv3_get_priority() to make input before output. - Check tcg_enabled() for gicv3_nmi_present(). - Update the comment for gicv3_nmi_present(). - Update the commit message. - Add Reviewed-by. - Add Suggested-by. Changes in v12: - pPriority<63> = ICC_AP1R_EL1NS<63> if HaveNMIExt() and HaveEL(EL3) and (IsNonSecure(), fix the wrong writing. - Do not check nmi_support repetitively in icc_hppi_can_preempt(), and icc_activate_irq, ich_highest_active_virt_prio(), hppvi_index(), icv_hppi_can_preempt(), icv_rpr_read() and icv_activate_irq(), gicv3_cpuif_virt_irq_fiq_update(). - Check hppi.nmi after check icc_hppi_can_preempt() for icc_iar1_read() and icc_nmiar1_read(). - When NMI is 1, the virtual interrupt's priority is 0x0. - Make the thisnmi logic more concisely in hppvi_index(). - Use is_nmi to simplify code and check is_nmi before comparing vpmr. - Also check sctlrx.NMI in icv_iar_read(). - Check icv_hppi_can_preempt() for icv_nmiar1_read(). - Check ICH_LR_EL2.NMI after check icv_hppi_can_preempt() as icv_iar_read() do it in icv_nmiar1_read(). - Correct thisnmi to bool in icv_eoir_write(). - Check thisnmi and nmi both true instead of identical in icv_eoir_write(). - nmi_needed -> gicv3_cpu_nmi_needed, needed_nmi -> gicv3_nmi_needed. - Correct the comment style in arm_cpu_initfn() and icv_nmiar1_read(). - Fix the typo, "prioirty" -> "priority". - Remove the redundant blank line. - Update the subject and commit message, hppi.superprio -> hppi.nmi, super priority -> non-maskable property. - Add Reviewed-by. Changes in v11: - Put vmstate_gicv3_cpu_nmi and
