Re: [PATCH v4 4/9] KVM: arm64: vgic: Let an interrupt controller advertise lack of HW deactivation

On Tue, 15 Jun 2021 15:26:02 +0100,
Alexandru Elisei [off-list ref] wrote:

Hi Marc,

On 6/1/21 11:40 AM, Marc Zyngier wrote:

quoted

The vGIC, as architected by ARM, allows a virtual interrupt to
trigger the deactivation of a physical interrupt. This allows
the following interrupt to be delivered without requiring an exit.

However, some implementations have choosen not to implement this,
meaning that we will need some unsavoury workarounds to deal with this.

On detecting such a case, taint the kernel and spit a nastygram.
We'll deal with this in later patches.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/vgic/vgic-init.c       | 10 ++++++++++
 include/kvm/arm_vgic.h                |  3 +++
 include/linux/irqchip/arm-vgic-info.h |  2 ++
 3 files changed, 15 insertions(+)

diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index 6752d084934d..340c51d87677 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c

@@ -532,6 +532,16 @@ int kvm_vgic_hyp_init(void)
 		return -ENXIO;
 	}
 
+	/*
+	 * If we get one of these oddball non-GICs, taint the kernel,
+	 * as we have no idea of how they *really* behave.
+	 */
+	if (gic_kvm_info->no_hw_deactivation) {
+		kvm_info("Non-architectural vgic, tainting kernel\n");
+		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);

I'm trying to figure out what are the effects of tainting the
kernel, besides those nasty messages. In
Documentation/admin-guide/tainted-kernels.rst, I found this bit:

[..] the information is mainly of interest once someone wants to
investigate some problem, as its real cause might be the event that
got the kernel tainted. That's why bug reports from tainted kernels
will often be ignored by developers, hence try to reproduce problems
with an untainted kernel.

The lack of HW deactivation affects only KVM, I was wondering if we
could taint the kernel the first time a VM created. If the above doc
is to go by, someone who is running Linux on an M1, but not using
KVM, might stand a better chance to get support when something goes
wrong in that case.

Unfortunately, by the time we're here, we have already committed to
using stuff that isn't architectural.

For example, this CPU doesn't advertise a virtual GICv3 CPU interface
(because it isn't possible to do so independently of the full-fat
one). And right from the beginning, before any VM is present, we are
going to access ICH_VTR_EL2, because we really need it as part of
initialising KVM.

What do you think?

I think that if people are bothered by this tainting, they can disable
KVM altogether. And to be fair, we should taint the kernel right when
the first CPU boots, because it isn't implementing the ARM
architecture as defined by the spec.

Thanks,

	M.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel