[PATCH for-stable-5.10 2/2] KVM: arm64: Workaround firmware wrongly advertising GICv2-on-v3 compatibility

[Marc Zyngier]

On Thu, 25 Mar 2021 09:37:15 +0000,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com> wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Marc Zyngier [mailto:maz at kernel.org]
> > Sent: 25 March 2021 09:33
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>
> > Cc: kvmarm at lists.cs.columbia.edu; kvm at vger.kernel.org;
> > linux-arm-kernel at lists.infradead.org; stable at vger.kernel.org;
> > pbonzini at redhat.com; Linuxarm <linuxarm at huawei.com>
> > Subject: Re: [PATCH for-stable-5.10 2/2] KVM: arm64: Workaround firmware
> > wrongly advertising GICv2-on-v3 compatibility
> > 
> > On 2021-03-25 09:14, Shameer Kolothum wrote:
> > > From: Marc Zyngier <maz at kernel.org>
> > >
> > > commit 9739f6ef053f104a997165701c6e15582c4307ee upstream.
> > >
> > > It looks like we have broken firmware out there that wrongly
> > > advertises a GICv2 compatibility interface, despite the CPUs not being
> > > able to deal with it.
> > >
> > > To work around this, check that the CPU initialising KVM is actually
> > > able to switch to MMIO instead of system registers, and use that as a
> > > precondition to enable GICv2 compatibility in KVM.
> > >
> > > Note that the detection happens on a single CPU. If the firmware is
> > > lying *and* that the CPUs are asymetric, all hope is lost anyway.
> > >
> > > Cc: stable at vger.kernel.org #5.10
> > > Reported-by: Shameerali Kolothum Thodi
> > > <shameerali.kolothum.thodi at huawei.com>
> > > Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
> > > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > > Message-Id: <20210305185254.3730990-8-maz at kernel.org>
> > > Signed-off-by: Paolo Bonzini <pbonzini at redhat.com>
> > > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
> > 
> > Please hold on on that.
> > 
> > This patch causes a regression, and needs a fix that is currently queued for 5.12
> > [1]. Once this hits upstream, please add the fix to the series and post it as a
> > whole.
> 
> Ok. Yes, I noted that. But was thinking if this goes through first
> and then we can have a stable tag for that one, we can manage
> it.

The problem is we'd end-up with 5.10 being subtly broken for a while,
and I want to avoid this.

Specially given that not having this series only affects broken
platforms, while having an incomplete series breaks working systems
(which is be counter productive).

> Anyway, will wait now.

Thanks for that,

	M.

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