Hi Marc,
On 6/1/21 11:40 AM, Marc Zyngier wrote:
> 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@xxxxxxxxxx>
> ---
> 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.
What do you think?
Thanks,
Alex
> + kvm_vgic_global_state.no_hw_deactivation = true;
> + }
> +
> switch (gic_kvm_info->type) {
> case GIC_V2:
> ret = vgic_v2_probe(gic_kvm_info);
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index ec621180ef09..e45b26e8d479 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -72,6 +72,9 @@ struct vgic_global {
> bool has_gicv4;
> bool has_gicv4_1;
>
> + /* Pseudo GICv3 from outer space */
> + bool no_hw_deactivation;
> +
> /* GIC system register CPU interface */
> struct static_key_false gicv3_cpuif;
>
> diff --git a/include/linux/irqchip/arm-vgic-info.h b/include/linux/irqchip/arm-vgic-info.h
> index 7c0d08ebb82c..a75b2c7de69d 100644
> --- a/include/linux/irqchip/arm-vgic-info.h
> +++ b/include/linux/irqchip/arm-vgic-info.h
> @@ -32,6 +32,8 @@ struct gic_kvm_info {
> bool has_v4;
> /* rvpeid support */
> bool has_v4_1;
> + /* Deactivation impared, subpar stuff */
> + bool no_hw_deactivation;
> };
>
> #ifdef CONFIG_KVM
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
