diff mbox series

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

Message ID 20210325091424.26348-3-shameerali.kolothum.thodi@huawei.com
State New
Headers show
Series Backport for- Work around firmware wrongly advertising GICv2 compatibility | expand

Commit Message

Shameerali Kolothum Thodi March 25, 2021, 9:14 a.m. UTC 
From: Marc Zyngier <maz@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@vger.kernel.org #5.10
Reported-by: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

Signed-off-by: Marc Zyngier <maz@kernel.org>

Message-Id: <20210305185254.3730990-8-maz@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

---
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 35 +++++++++++++++++++++++++++++++--
 arch/arm64/kvm/vgic/vgic-v3.c   |  8 ++++++--
 2 files changed, 39 insertions(+), 4 deletions(-)

-- 
2.17.1

Comments

Marc Zyngier March 25, 2021, 9:33 a.m. UTC | #1 
On 2021-03-25 09:14, Shameer Kolothum wrote:
> From: Marc Zyngier <maz@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@vger.kernel.org #5.10

> Reported-by: Shameerali Kolothum Thodi 

> <shameerali.kolothum.thodi@huawei.com>

> Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

> Signed-off-by: Marc Zyngier <maz@kernel.org>

> Message-Id: <20210305185254.3730990-8-maz@kernel.org>

> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@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.

Thanks,

         M.

[1] https://lore.kernel.org/r/20210323162301.2049595-1-maz@kernel.org
-- 
Jazz is not dead. It just smells funny...
Shameerali Kolothum Thodi March 25, 2021, 9:37 a.m. UTC | #2 
> -----Original Message-----

> From: Marc Zyngier [mailto:maz@kernel.org]

> Sent: 25 March 2021 09:33

> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>

> Cc: kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org;

> linux-arm-kernel@lists.infradead.org; stable@vger.kernel.org;

> pbonzini@redhat.com; Linuxarm <linuxarm@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@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@vger.kernel.org #5.10

> > Reported-by: Shameerali Kolothum Thodi

> > <shameerali.kolothum.thodi@huawei.com>

> > Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

> > Signed-off-by: Marc Zyngier <maz@kernel.org>

> > Message-Id: <20210305185254.3730990-8-maz@kernel.org>

> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@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. Anyway, will wait now.

Thanks,
Shameer
 
> Thanks,

> 

>          M.

> 

> [1] https://lore.kernel.org/r/20210323162301.2049595-1-maz@kernel.org

> --

> Jazz is not dead. It just smells funny...
Marc Zyngier March 25, 2021, 9:54 a.m. UTC | #3 
On Thu, 25 Mar 2021 09:37:15 +0000,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> wrote:
> 

> 

> 

> > -----Original Message-----

> > From: Marc Zyngier [mailto:maz@kernel.org]

> > Sent: 25 March 2021 09:33

> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>

> > Cc: kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org;

> > linux-arm-kernel@lists.infradead.org; stable@vger.kernel.org;

> > pbonzini@redhat.com; Linuxarm <linuxarm@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@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@vger.kernel.org #5.10

> > > Reported-by: Shameerali Kolothum Thodi

> > > <shameerali.kolothum.thodi@huawei.com>

> > > Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

> > > Signed-off-by: Marc Zyngier <maz@kernel.org>

> > > Message-Id: <20210305185254.3730990-8-maz@kernel.org>

> > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

> > > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@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.
Greg KH March 25, 2021, 11:38 a.m. UTC | #4 
On Thu, Mar 25, 2021 at 09:33:17AM +0000, Marc Zyngier wrote:
> On 2021-03-25 09:14, Shameer Kolothum wrote:

> > From: Marc Zyngier <maz@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@vger.kernel.org #5.10

> > Reported-by: Shameerali Kolothum Thodi

> > <shameerali.kolothum.thodi@huawei.com>

> > Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

> > Signed-off-by: Marc Zyngier <maz@kernel.org>

> > Message-Id: <20210305185254.3730990-8-maz@kernel.org>

> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@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.


Both patches now dropped from my queue, thanks.

greg k-h
diff mbox series

Patch

diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index 54ce4048d7d1..098b96c121e3 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -406,11 +406,42 @@  void __vgic_v3_init_lrs(void)
 /*
  * Return the GIC CPU configuration:
  * - [31:0]  ICH_VTR_EL2
- * - [63:32] RES0
+ * - [62:32] RES0
+ * - [63]    MMIO (GICv2) capable
  */
 u64 __vgic_v3_get_gic_config(void)
 {
-	return read_gicreg(ICH_VTR_EL2);
+	u64 val, sre = read_gicreg(ICC_SRE_EL1);
+	unsigned long flags = 0;
+
+	/*
+	 * To check whether we have a MMIO-based (GICv2 compatible)
+	 * CPU interface, we need to disable the system register
+	 * view. To do that safely, we have to prevent any interrupt
+	 * from firing (which would be deadly).
+	 *
+	 * Note that this only makes sense on VHE, as interrupts are
+	 * already masked for nVHE as part of the exception entry to
+	 * EL2.
+	 */
+	if (has_vhe())
+		flags = local_daif_save();
+
+	write_gicreg(0, ICC_SRE_EL1);
+	isb();
+
+	val = read_gicreg(ICC_SRE_EL1);
+
+	write_gicreg(sre, ICC_SRE_EL1);
+	isb();
+
+	if (has_vhe())
+		local_daif_restore(flags);
+
+	val  = (val & ICC_SRE_EL1_SRE) ? 0 : (1ULL << 63);
+	val |= read_gicreg(ICH_VTR_EL2);
+
+	return val;
 }
 
 u64 __vgic_v3_read_vmcr(void)
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 8e7bf3151057..6a4bced0851d 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-v3.c
@@ -584,8 +584,10 @@  early_param("kvm-arm.vgic_v4_enable", early_gicv4_enable);
 int vgic_v3_probe(const struct gic_kvm_info *info)
 {
 	u64 ich_vtr_el2 = kvm_call_hyp_ret(__vgic_v3_get_gic_config);
+	bool has_v2;
 	int ret;
 
+	has_v2 = ich_vtr_el2 >> 63;
 	ich_vtr_el2 = (u32)ich_vtr_el2;
 
 	/*
@@ -605,13 +607,15 @@  int vgic_v3_probe(const struct gic_kvm_info *info)
 			 gicv4_enable ? "en" : "dis");
 	}
 
+	kvm_vgic_global_state.vcpu_base = 0;
+
 	if (!info->vcpu.start) {
 		kvm_info("GICv3: no GICV resource entry\n");
-		kvm_vgic_global_state.vcpu_base = 0;
+	} else if (!has_v2) {
+		pr_warn(FW_BUG "CPU interface incapable of MMIO access\n");
 	} else if (!PAGE_ALIGNED(info->vcpu.start)) {
 		pr_warn("GICV physical address 0x%llx not page aligned\n",
 			(unsigned long long)info->vcpu.start);
-		kvm_vgic_global_state.vcpu_base = 0;
 	} else {
 		kvm_vgic_global_state.vcpu_base = info->vcpu.start;
 		kvm_vgic_global_state.can_emulate_gicv2 = true;