On Tue, 15 Jun 2021 15:26:02 +0100,
Alexandru Elisei <alexandru.elisei@xxxxxxx> wrote:
>
> 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.
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.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
