[PATCH v2 12/14] arm64/nmi: Add handling of superpriority interrupts as NMIs

Mark Brown broonie at kernel.org
Wed Dec 7 11:15:01 PST 2022


On Wed, Dec 07, 2022 at 06:57:32PM +0000, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

> > Any CPU new enough to have FEAT_NMI is architecturally required to also
> > have FEAT_CSV2 since that's mandatory since v8.5 and FEAT_NMI is a v8.8
> > feature.  FEAT_CSV2 means the hardware doesn't need the mitigation, and

> "Hypothetically", CPUs that advertise CSV2 could subsequently be found
> to actually require extra handling, and I really wouldn't take such a
> bet.

> The reasoning by which CPU designers follow the ARM feature dependency
> rules doesn't hold any water either, and hasn't for years (ARM itself
> has been backporting features into CPUs that have a much older base
> architecture). You don't have to look very far to find implementations
> that cherry-pick whatever they want. The sad reality is that nobody
> gives a damn about this rule, and ultimately pick whatever they see
> fit.

My guess would be that the Spectre stuff is generally considered
sufficiently important that it'd also get mitigated but as you say you
never know.

> And given that this is only one static branch away, that the runtime
> cost is likely to be a big fat zero for non-affected platforms, for an
> event that is vanishingly rare anyway, I'd rather we stay consistent
> in the whole interrupt path and keep the mitigation code in.

Yeah, that's certainly a valid argument and I do tend to agree that it's
better defensive programming - like I said I was trying to thread a
needle between the two anticipated review reactions.  I'll hold off for
now in case anyone else has strong opinions in the other direction
though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20221207/859152d6/attachment.sig>


More information about the linux-arm-kernel mailing list