[PATCH v2 09/14] KVM: arm64: Hide FEAT_NMI from guests

[Mark Brown]

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

> > > > We do not need to check for FEAT_HCRX since it is mandatory since v8.7
> > > > and FEAT_NMI is a v8.8 feature.

> > > And yet you check for it in hyp-stub.S after having checked for
> > > FEAT_NMI. What gives?

> > Being aware that you have a strong preference for not having safety
> > checks for mandatory features I didn't add any here but noted it so
> > people could see why they were omitted.  The checks in hyp-stub.S were
> > probably written before I'd checked the dependency situation out.

> > I can remove those checks if preferred but TBH given that the failure
> > mode in hyp-stub.S is typically going to be to die with no output if
> > something goes wrong it does feel like it's worth the extra couple of
> > instructions to double check things just in case, especially with the
> > virtual platforms being so easy to misconfigure.

> I'm not hell bent on it, and if we can spot the issue early, that's
> fine by me. But let's then disable the feature if the implementation
> lacks some essential dependencies.

> A simple check on ID_AA64MMFR1_EL1.HCX when detecting FEAT_NMI should
> do the trick.

Hrm, we should really only check if EL2 is implemented since that is a
valid configuration in which HCX is moot, and there's a case for only
checking when we entered the kernel at EL2 since otherwise any traps to
EL2 are not really our problem and I can see why EL2 might not let EL1
know about the feature even if it really should.
-------------- 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/638d3516/attachment-0001.sig>