[PATCH v2 08/14] arm64/cpufeature: Detect PE support for FEAT_NMI

Mark Brown broonie at kernel.org
Mon Dec 5 11:32:01 PST 2022


On Mon, Dec 05, 2022 at 06:03:07PM +0000, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

> > +#ifdef CONFIG_ARM64_NMI
> > +	{
> > +		.desc = "Non-maskable Interrupts",
> > +		.capability = ARM64_HAS_NMI,
> > +		.type = ARM64_CPUCAP_BOOT_CPU_FEATURE,

> PSEUDO_NMI uses ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE. What is the
> rational for using a different policy here?

I couldn't identify any issues that the kernel would have if the feature
was present in the hardware but unused so I didn't see the need to be
additionally restrictive.  TBH I'm not 100% clear why the _STRICT is
there for pseudo NMIs, it seemed a bit out of scope for this series to
try to clean that up though.

> The whole thing is way too restrictive: KVM definitely needs to know
> that the feature exists, even if there is no use for it in the host
> kernel. There is no reason why guests shouldn't be able to use this
> even if the host doesn't care about it.

> Which means you need two properties: one that advertises the
> availability of the feature, and one that makes use of it in the
> kernel.

To be clear I think what you're looking for here is a capability that
omits the cross-check with pseudo NMIs rather than something that's
strictly checking the hardware (so ID register overrides will still
apply)?  I've done that locally, my tree currently has capabilites
HAS_NMI and USES_NMI.
-------------- 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/20221205/d9399561/attachment.sig>


More information about the linux-arm-kernel mailing list