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

[Marc Zyngier]

On Mon, 05 Dec 2022 19:32:01 +0000,
Mark Brown <broonie at kernel.org> wrote:
> 
> 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.

Suzuki is your man for this, adding him to the party.

> 
> > 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.

Something like that, yes. And HAS_NMI should be unconditionally
enabled (command-line overrides notwithstanding).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.