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

Marc Zyngier
2022-12-07T19:08:19Z

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