[PATCH v2 0/4] Add workaround for HIP10/HIP10C erratum 162200802

[PATCH v2 0/4] Add workaround for HIP10/HIP10C erratum 162200802

[Zhou Wang]

As the discussion from V1 series, V2 series firstly adds GICD.num_LPIs
writable support, then add HiSilicon erratum 162200802.

Erratum number should be 162200802, make a mistake in V1, so fix it as
well.

Zhou Wang (4):
  KVM: arm64: Allow userspace to write GICD_TYPER.num_LPIs
  KVM: arm64: selftests: Add test for GICD.num_LPIs
  Documentation: KVM: arm64: Add GICD_TYPER.num_LPIs writable
    description
  ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200802

 Documentation/arch/arm64/silicon-errata.rst   |  2 ++
 .../virt/kvm/devices/arm-vgic-v3.rst          |  6 ++++
 arch/arm64/Kconfig                            | 12 +++++++
 arch/arm64/include/asm/cputype.h              |  4 +++
 arch/arm64/kernel/cpu_errata.c                | 15 +++++++++
 arch/arm64/kvm/vgic/vgic-init.c               |  9 +++++
 arch/arm64/kvm/vgic/vgic-its.c                |  9 +++--
 arch/arm64/kvm/vgic/vgic-kvm-device.c         |  1 +
 arch/arm64/kvm/vgic/vgic-mmio-v3.c            | 22 +++++++++++++
 arch/arm64/tools/cpucaps                      |  1 +
 include/kvm/arm_vgic.h                        |  1 +
 include/linux/irqchip/arm-gic-v3.h            |  1 +
 tools/testing/selftests/kvm/arm64/vgic_init.c | 33 +++++++++++++++++++
 .../selftests/kvm/include/arm64/gic_v3.h      |  2 ++
 14 files changed, 116 insertions(+), 2 deletions(-)

-- 
2.33.0

[PATCH v2 1/4] KVM: arm64: Allow userspace to write GICD_TYPER.num_LPIs

[Zhou Wang]

Allow userspace to write GICD_TYPER.num_LPIs. If GICD_TYPER.num_LPIs is
0, number of LPIs is indicated by GICD_TYPER.IDbits, so the default
value of GICD_TYPER.num_LPIs is still set as 0.

Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
---
 arch/arm64/kvm/vgic/vgic-init.c       |  2 ++
 arch/arm64/kvm/vgic/vgic-its.c        |  9 +++++++--
 arch/arm64/kvm/vgic/vgic-kvm-device.c |  1 +
 arch/arm64/kvm/vgic/vgic-mmio-v3.c    | 16 ++++++++++++++++
 include/kvm/arm_vgic.h                |  1 +
 include/linux/irqchip/arm-gic-v3.h    |  1 +
 6 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index 1e680ad6e863..46468cb97536 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -389,6 +389,7 @@ int vgic_init(struct kvm *kvm)
 	/* freeze the number of spis */
 	if (!dist->nr_spis)
 		dist->nr_spis = VGIC_NR_IRQS_LEGACY - VGIC_NR_PRIVATE_IRQS;
+	dist->nr_lpis = 0;
 
 	ret = kvm_vgic_dist_init(kvm, dist->nr_spis);
 	if (ret)
@@ -428,6 +429,7 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm)
 	kfree(dist->spis);
 	dist->spis = NULL;
 	dist->nr_spis = 0;
+	dist->nr_lpis = 0;
 	dist->vgic_dist_base = VGIC_ADDR_UNDEF;
 
 	if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) {
diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 7368c13f16b7..d8ee617cfa6f 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -377,9 +377,14 @@ static void update_affinity_collection(struct kvm *kvm, struct vgic_its *its,
 	}
 }
 
-static u32 max_lpis_propbaser(u64 propbaser)
+static u32 max_lpis_propbaser(struct vgic_dist *dist)
 {
+	u64 propbaser = dist->propbaser;
 	int nr_idbits = (propbaser & 0x1f) + 1;
+	int nr_lpis = dist->nr_lpis;
+
+	if (nr_lpis)
+		return min(8192 + nr_lpis, 1 << nr_idbits);
 
 	return 1U << min(nr_idbits, INTERRUPT_ID_BITS_ITS);
 }
@@ -1047,7 +1052,7 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its,
 	else
 		lpi_nr = event_id;
 	if (lpi_nr < GIC_LPI_OFFSET ||
-	    lpi_nr >= max_lpis_propbaser(kvm->arch.vgic.propbaser))
+	    lpi_nr >= max_lpis_propbaser(&kvm->arch.vgic))
 		return E_ITS_MAPTI_PHYSICALID_OOR;
 
 	/* If there is an existing mapping, behavior is UNPREDICTABLE. */
diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c b/arch/arm64/kvm/vgic/vgic-kvm-device.c
index 3d1a776b716d..f4268b60c4dd 100644
--- a/arch/arm64/kvm/vgic/vgic-kvm-device.c
+++ b/arch/arm64/kvm/vgic/vgic-kvm-device.c
@@ -514,6 +514,7 @@ static bool reg_allowed_pre_init(struct kvm_device_attr *attr)
 		return false;
 
 	switch (attr->attr & KVM_DEV_ARM_VGIC_OFFSET_MASK) {
+	case GICD_TYPER:
 	case GICD_IIDR:
 	case GICD_TYPER2:
 		return true;
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index a3ef185209e9..3a53b63f7b20 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -90,6 +90,8 @@ static unsigned long vgic_mmio_read_v3_misc(struct kvm_vcpu *vcpu,
 		if (vgic_has_its(vcpu->kvm)) {
 			value |= (INTERRUPT_ID_BITS_ITS - 1) << 19;
 			value |= GICD_TYPER_LPIS;
+			if (vgic->nr_lpis)
+				value |= (ilog2(vgic->nr_lpis) - 1) << 11;
 		} else {
 			value |= (INTERRUPT_ID_BITS_SPIS - 1) << 19;
 		}
@@ -167,6 +169,20 @@ static int vgic_mmio_uaccess_write_v3_misc(struct kvm_vcpu *vcpu,
 	u32 reg;
 
 	switch (addr & 0x0c) {
+	case GICD_TYPER:
+		reg = vgic_mmio_read_v3_misc(vcpu, addr, len);
+
+		if (reg == val)
+			return 0;
+		if (vgic_initialized(vcpu->kvm))
+			return -EBUSY;
+		if ((reg ^ val) & ~GICD_TYPER_NUM_LPIS_MASK)
+			return -EINVAL;
+		if (GICD_TYPER_NUM_LPIS(val) > INTERRUPT_ID_BITS_ITS)
+			return -EINVAL;
+
+		dist->nr_lpis = 2 ^ GICD_TYPER_NUM_LPIS(val);
+		return 0;
 	case GICD_TYPER2:
 		reg = vgic_mmio_read_v3_misc(vcpu, addr, len);
 
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 404883c7af6e..774bfd008230 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -303,6 +303,7 @@ struct vgic_dist {
 	 * else.
 	 */
 	struct its_vm		its_vm;
+	int			nr_lpis;
 };
 
 struct vgic_v2_cpu_if {
diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
index 70c0948f978e..517d9f2edc44 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -85,6 +85,7 @@
 #define GICD_TYPER_ESPI			(1U << 8)
 
 #define GICD_TYPER_ID_BITS(typer)	((((typer) >> 19) & 0x1f) + 1)
+#define GICD_TYPER_NUM_LPIS_MASK	GENMASK(15, 11)
 #define GICD_TYPER_NUM_LPIS(typer)	((((typer) >> 11) & 0x1f) + 1)
 #define GICD_TYPER_SPIS(typer)		((((typer) & 0x1f) + 1) * 32)
 #define GICD_TYPER_ESPIS(typer)						\
-- 
2.33.0

[PATCH v2 2/4] KVM: arm64: selftests: Add test for GICD.num_LPIs

[Zhou Wang]

Add test case about GICD.num_LPIs. The default value should be 0, and it
can be modified before GIC init, but cannot be modified after GIC init.

Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
---
 tools/testing/selftests/kvm/arm64/vgic_init.c | 33 +++++++++++++++++++
 .../selftests/kvm/include/arm64/gic_v3.h      |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/tools/testing/selftests/kvm/arm64/vgic_init.c b/tools/testing/selftests/kvm/arm64/vgic_init.c
index a8e0f46bc0ab..7e60443827e9 100644
--- a/tools/testing/selftests/kvm/arm64/vgic_init.c
+++ b/tools/testing/selftests/kvm/arm64/vgic_init.c
@@ -968,6 +968,38 @@ static void test_v3_sysregs(void)
 	kvm_vm_free(vm);
 }
 
+static void test_v3_num_lpis(void)
+{
+	struct kvm_vcpu *vcpus[NR_VCPUS];
+	u32 num_lpis;
+	struct vm_gic vm;
+	u32 typer;
+	int ret;
+
+	vm = vm_gic_create_with_vcpus(KVM_DEV_TYPE_ARM_VGIC_V3, NR_VCPUS, vcpus);
+	kvm_create_device(vm.vm, KVM_DEV_TYPE_ARM_VGIC_ITS);
+
+	kvm_device_attr_get(vm.gic_fd, KVM_DEV_ARM_VGIC_GRP_DIST_REGS,
+			    GICD_TYPER, &typer);
+	num_lpis = typer & GICD_TYPER_NUM_LPIS_MASK;
+	TEST_ASSERT(!num_lpis, "Default value of GICD.num_LPIs is not 0");
+
+	typer |= 10 << GICD_TYPER_NUM_LPIS_SHIFT;
+	ret = __kvm_device_attr_set(vm.gic_fd, KVM_DEV_ARM_VGIC_GRP_DIST_REGS,
+				    GICD_TYPER, &typer);
+	TEST_ASSERT(!ret, KVM_IOCTL_ERROR(KVM_DEVICE_ATTR_SET, ret));
+
+	kvm_device_attr_set(vm.gic_fd, KVM_DEV_ARM_VGIC_GRP_CTRL,
+			    KVM_DEV_ARM_VGIC_CTRL_INIT, NULL);
+
+	ret = __kvm_device_attr_set(vm.gic_fd, KVM_DEV_ARM_VGIC_GRP_DIST_REGS,
+				    GICD_TYPER, &typer);
+	TEST_ASSERT(ret && errno == EBUSY,
+		    "Changed GICD.num_LPIs after initializing the VGIC");
+
+	vm_gic_destroy(&vm);
+}
+
 void run_tests(uint32_t gic_dev_type)
 {
 	test_vcpus_then_vgic(gic_dev_type);
@@ -985,6 +1017,7 @@ void run_tests(uint32_t gic_dev_type)
 		test_v3_its_region();
 		test_v3_sysregs();
 		test_v3_nassgicap();
+		test_v3_num_lpis();
 	}
 }
 
diff --git a/tools/testing/selftests/kvm/include/arm64/gic_v3.h b/tools/testing/selftests/kvm/include/arm64/gic_v3.h
index a76615fa39a1..c9f25cdd3651 100644
--- a/tools/testing/selftests/kvm/include/arm64/gic_v3.h
+++ b/tools/testing/selftests/kvm/include/arm64/gic_v3.h
@@ -85,6 +85,8 @@
 #define GICD_TYPER_ESPI			(1U << 8)
 
 #define GICD_TYPER_ID_BITS(typer)	((((typer) >> 19) & 0x1f) + 1)
+#define GICD_TYPER_NUM_LPIS_MASK	GENMASK(15, 11)
+#define GICD_TYPER_NUM_LPIS_SHIFT	11
 #define GICD_TYPER_NUM_LPIS(typer)	((((typer) >> 11) & 0x1f) + 1)
 #define GICD_TYPER_SPIS(typer)		((((typer) & 0x1f) + 1) * 32)
 #define GICD_TYPER_ESPIS(typer)						\
-- 
2.33.0

[PATCH v2 3/4] Documentation: KVM: arm64: Add GICD_TYPER.num_LPIs writable description

[Zhou Wang]

Add GICD_TYPER.num_LPIs writable description.

Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
---
 Documentation/virt/kvm/devices/arm-vgic-v3.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/virt/kvm/devices/arm-vgic-v3.rst b/Documentation/virt/kvm/devices/arm-vgic-v3.rst
index ff02102f7141..f4bd63e10b99 100644
--- a/Documentation/virt/kvm/devices/arm-vgic-v3.rst
+++ b/Documentation/virt/kvm/devices/arm-vgic-v3.rst
@@ -127,6 +127,7 @@ Groups:
 
       * GICD_IIDR.Revision
       * GICD_TYPER2.nASSGIcap
+      * GICD_TYPER.num_LPIs
 
     GICD_IIDR.Revision is updated when the KVM implementation is changed in a
     way directly observable by the guest or userspace.  Userspace should read
@@ -142,6 +143,11 @@ Groups:
     to determine the supported value(s) before writing to the field.
 
 
+    GICD_TYPER.num_LPIs allows userspace to control the maximum value of
+    supported LPIs. At VGIC creation the field resets to 0 which indicates
+    maximum value of supported LPIs is defined by GICD.IDbits.
+
+
     The GICD_STATUSR and GICR_STATUSR registers are architecturally defined such
     that a write of a clear bit has no effect, whereas a write with a set bit
     clears that value.  To allow userspace to freely set the values of these two
-- 
2.33.0

[PATCH v2 4/4] ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200802

[Zhou Wang]

For GICv4.0 of Hip10 and Hip10C, it has a SoC bug with vPE schedule:
when multiple vPEs are sending vpe schedule/deschedule commands
concurrently and repeatedly, some vPE schedule command may not be
scheduled, and it will cause the command timeout.

The hardware implementation is that there is one GIC hardware in one CPU die,
which handles all vPE schedule operations one by one in all CPUs of this die.
The bug is that if the number of queued vPE schedule operations is more
than a certain value, the last vPE schedule operation will be lost.

One possible way to solve this problem is to limit the number of vLPIs, so
the hardware could spend less time to scan virtual pending table when it
handles the vPE schedule operations, so the queued vPE schedule operations
will never be more than above certain value.

Given the number of CPUs of die, and imagine there is 100 vPE schedule
operations per second one CPU, it can be calculated that we can limit
the number of vLPI to 4096 for virtual machine to avoid the issue.

Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
---
 Documentation/arch/arm64/silicon-errata.rst |  2 ++
 arch/arm64/Kconfig                          | 12 ++++++++++++
 arch/arm64/include/asm/cputype.h            |  4 ++++
 arch/arm64/kernel/cpu_errata.c              | 15 +++++++++++++++
 arch/arm64/kvm/vgic/vgic-init.c             |  9 ++++++++-
 arch/arm64/kvm/vgic/vgic-mmio-v3.c          |  6 ++++++
 arch/arm64/tools/cpucaps                    |  1 +
 7 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index b18ef4064bc0..0de545c1fce5 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -264,6 +264,8 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | Hisilicon      | Hip09           | #162100801      | HISILICON_ERRATUM_162100801 |
 +----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon      | Hip{10,10C}     | #162200802      | HISILICON_ERRATUM_162200802 |
++----------------+-----------------+-----------------+-----------------------------+
 +----------------+-----------------+-----------------+-----------------------------+
 | Qualcomm Tech. | Kryo/Falkor v1  | E1003           | QCOM_FALKOR_ERRATUM_1003    |
 +----------------+-----------------+-----------------+-----------------------------+
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e9bbfacc35a6..a43a341047a2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1270,6 +1270,18 @@ config HISILICON_ERRATUM_162100801
 
 	  If unsure, say Y.
 
+config HISILICON_ERRATUM_162200802
+	bool "Hip{10, 10C} 162200802 erratum support"
+	default y
+	help
+	  For GICv4.0 of Hip10 and Hip10C, it has a soc bug with vPE schedule:
+	  when multiple vPEs are sending vpe schedule/deschedule commands
+	  concurrently and repeatly, some vPE schedule command may not be
+	  scheduled, and it will cause the command timeout. To avoid the
+	  issue, limit the number of vLPI to 4096 for virtual machine.
+
+	  If unsure, say Y.
+
 config QCOM_FALKOR_ERRATUM_1003
 	bool "Falkor E1003: Incorrect translation due to ASID change"
 	default y
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 661735616787..c40328907433 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -134,6 +134,8 @@
 
 #define HISI_CPU_PART_TSV110		0xD01
 #define HISI_CPU_PART_HIP09			0xD02
+#define HISI_CPU_PART_HIP10		0xD03
+#define HISI_CPU_PART_HIP10C		0xD45
 #define HISI_CPU_PART_HIP12		0xD06
 
 #define APPLE_CPU_PART_M1_ICESTORM	0x022
@@ -223,6 +225,8 @@
 #define MIDR_FUJITSU_A64FX MIDR_CPU_MODEL(ARM_CPU_IMP_FUJITSU, FUJITSU_CPU_PART_A64FX)
 #define MIDR_HISI_TSV110 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV110)
 #define MIDR_HISI_HIP09 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_HIP09)
+#define MIDR_HISI_HIP10 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_HIP10)
+#define MIDR_HISI_HIP10C MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_HIP10C)
 #define MIDR_HISI_HIP12 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_HIP12)
 #define MIDR_APPLE_M1_ICESTORM MIDR_CPU_MODEL(ARM_CPU_IMP_APPLE, APPLE_CPU_PART_M1_ICESTORM)
 #define MIDR_APPLE_M1_FIRESTORM MIDR_CPU_MODEL(ARM_CPU_IMP_APPLE, APPLE_CPU_PART_M1_FIRESTORM)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 59d723c9ab8f..c97a65d799db 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -564,6 +564,14 @@ static const struct midr_range erratum_ac04_cpu_23_list[] = {
 };
 #endif
 
+#ifdef CONFIG_HISILICON_ERRATUM_162200802
+static const struct midr_range erratum_hisi_162200802[] = {
+	MIDR_ALL_VERSIONS(MIDR_HISI_HIP10),
+	MIDR_ALL_VERSIONS(MIDR_HISI_HIP10C),
+	{},
+};
+#endif
+
 const struct arm64_cpu_capabilities arm64_errata[] = {
 #ifdef CONFIG_ARM64_WORKAROUND_CLEAN_CACHE
 	{
@@ -905,6 +913,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
 		.matches = has_impdef_pmuv3,
 		.cpu_enable = cpu_enable_impdef_pmuv3_traps,
 	},
+#ifdef CONFIG_HISILICON_ERRATUM_162200802
+	{
+		.desc = "HiSilicon erratum 162200802",
+		.capability = ARM64_WORKAROUND_HISI_162200802,
+		ERRATA_MIDR_RANGE_LIST(erratum_hisi_162200802),
+	},
+#endif
 	{
 	}
 };
diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index 46468cb97536..306ae6f55983 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -389,7 +389,14 @@ int vgic_init(struct kvm *kvm)
 	/* freeze the number of spis */
 	if (!dist->nr_spis)
 		dist->nr_spis = VGIC_NR_IRQS_LEGACY - VGIC_NR_PRIVATE_IRQS;
-	dist->nr_lpis = 0;
+
+	if (cpus_have_final_cap(ARM64_WORKAROUND_HISI_162200802) &&
+	    kvm_vgic_global_state.has_gicv4 &&
+	    !kvm_vgic_global_state.has_gicv4_1)
+		dist->nr_lpis = 4096;
+	else
+		dist->nr_lpis = 0;
+
 
 	ret = kvm_vgic_dist_init(kvm, dist->nr_spis);
 	if (ret)
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 3a53b63f7b20..477d6af4a709 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -180,6 +180,12 @@ static int vgic_mmio_uaccess_write_v3_misc(struct kvm_vcpu *vcpu,
 			return -EINVAL;
 		if (GICD_TYPER_NUM_LPIS(val) > INTERRUPT_ID_BITS_ITS)
 			return -EINVAL;
+		/* Limit the number of vlpis to 4096 */
+		if (cpus_have_final_cap(ARM64_WORKAROUND_HISI_162200802) &&
+		    kvm_vgic_global_state.has_gicv4 &&
+		    !kvm_vgic_global_state.has_gicv4_1 &&
+		    GICD_TYPER_NUM_LPIS(val) != 12)
+			return -EINVAL;
 
 		dist->nr_lpis = 2 ^ GICD_TYPER_NUM_LPIS(val);
 		return 0;
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index ef0b7946f5a4..e39bd95dea74 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -111,6 +111,7 @@ WORKAROUND_CAVIUM_TX2_219_PRFM
 WORKAROUND_CAVIUM_TX2_219_TVM
 WORKAROUND_CLEAN_CACHE
 WORKAROUND_DEVICE_LOAD_ACQUIRE
+WORKAROUND_HISI_162200802
 WORKAROUND_NVIDIA_CARMEL_CNP
 WORKAROUND_PMUV3_IMPDEF_TRAPS
 WORKAROUND_QCOM_FALKOR_E1003
-- 
2.33.0

Re: [PATCH v2 0/4] Add workaround for HIP10/HIP10C erratum 162200802

[Zhou Wang]

On 2025/8/25 10:39, Zhou Wang wrote:
> As the discussion from V1 series, V2 series firstly adds GICD.num_LPIs
> writable support, then add HiSilicon erratum 162200802.
> 
> Erratum number should be 162200802, make a mistake in V1, so fix it as
> well.
> 
> Zhou Wang (4):
>   KVM: arm64: Allow userspace to write GICD_TYPER.num_LPIs
>   KVM: arm64: selftests: Add test for GICD.num_LPIs
>   Documentation: KVM: arm64: Add GICD_TYPER.num_LPIs writable
>     description
>   ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200802

Hi Marc and Oliver,

As the discussion in V1 series, this series firstly adds GICD.num_LPIs
writable support, then add erratum patch.

If this series is OK, I will prepare QEMU related patch.

BTW v1 is https://lore.kernel.org/all/20250626124142.2035110-1-wangzhou1@hisilicon.com/

Best,
Zhou

> 
>  Documentation/arch/arm64/silicon-errata.rst   |  2 ++
>  .../virt/kvm/devices/arm-vgic-v3.rst          |  6 ++++
>  arch/arm64/Kconfig                            | 12 +++++++
>  arch/arm64/include/asm/cputype.h              |  4 +++
>  arch/arm64/kernel/cpu_errata.c                | 15 +++++++++
>  arch/arm64/kvm/vgic/vgic-init.c               |  9 +++++
>  arch/arm64/kvm/vgic/vgic-its.c                |  9 +++--
>  arch/arm64/kvm/vgic/vgic-kvm-device.c         |  1 +
>  arch/arm64/kvm/vgic/vgic-mmio-v3.c            | 22 +++++++++++++
>  arch/arm64/tools/cpucaps                      |  1 +
>  include/kvm/arm_vgic.h                        |  1 +
>  include/linux/irqchip/arm-gic-v3.h            |  1 +
>  tools/testing/selftests/kvm/arm64/vgic_init.c | 33 +++++++++++++++++++
>  .../selftests/kvm/include/arm64/gic_v3.h      |  2 ++
>  14 files changed, 116 insertions(+), 2 deletions(-)
> 

Re: [PATCH v2 0/4] Add workaround for HIP10/HIP10C erratum 162200802

[Marc Zyngier]

On Mon, 01 Sep 2025 11:55:49 +0100,
Zhou Wang <wangzhou1@hisilicon.com> wrote:
> 
> On 2025/8/25 10:39, Zhou Wang wrote:
> > As the discussion from V1 series, V2 series firstly adds GICD.num_LPIs
> > writable support, then add HiSilicon erratum 162200802.
> > 
> > Erratum number should be 162200802, make a mistake in V1, so fix it as
> > well.
> > 
> > Zhou Wang (4):
> >   KVM: arm64: Allow userspace to write GICD_TYPER.num_LPIs
> >   KVM: arm64: selftests: Add test for GICD.num_LPIs
> >   Documentation: KVM: arm64: Add GICD_TYPER.num_LPIs writable
> >     description
> >   ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200802
> 
> Hi Marc and Oliver,
> 
> As the discussion in V1 series, this series firstly adds GICD.num_LPIs
> writable support, then add erratum patch.

Given the state of this HW (as per [1]), I'd rather we start by
working out the strategy at the GIC level, rather than exposing stuff
to userspace before we agree on a way to make it work in the kernel.

Thanks,

	M.

[1] https://lore.kernel.org/r/20250909110615.129179-1-wangzhou1@hisilicon.com

-- 
Jazz isn't dead. It just smells funny.

Re: [PATCH v2 0/4] Add workaround for HIP10/HIP10C erratum 162200802

[Zhou Wang]

On 2025/9/19 23:52, Marc Zyngier wrote:
> On Mon, 01 Sep 2025 11:55:49 +0100,
> Zhou Wang <wangzhou1@hisilicon.com> wrote:
>>
>> On 2025/8/25 10:39, Zhou Wang wrote:
>>> As the discussion from V1 series, V2 series firstly adds GICD.num_LPIs
>>> writable support, then add HiSilicon erratum 162200802.
>>>
>>> Erratum number should be 162200802, make a mistake in V1, so fix it as
>>> well.
>>>
>>> Zhou Wang (4):
>>>   KVM: arm64: Allow userspace to write GICD_TYPER.num_LPIs
>>>   KVM: arm64: selftests: Add test for GICD.num_LPIs
>>>   Documentation: KVM: arm64: Add GICD_TYPER.num_LPIs writable
>>>     description
>>>   ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200802
>>
>> Hi Marc and Oliver,
>>
>> As the discussion in V1 series, this series firstly adds GICD.num_LPIs
>> writable support, then add erratum patch.
> 
> Given the state of this HW (as per [1]), I'd rather we start by
> working out the strategy at the GIC level, rather than exposing stuff
> to userspace before we agree on a way to make it work in the kernel.

This bug is in GICv4.0([1] is in GICv4.1), and seems having a clear way
to fix. How about merging this fix firstly, then continue to try to solve [1]?

Best,
Zhou

> 
> Thanks,
> 
> 	M.
> 
> [1] https://lore.kernel.org/r/20250909110615.129179-1-wangzhou1@hisilicon.com
> 

Re: [PATCH v2 0/4] Add workaround for HIP10/HIP10C erratum 162200802

[Marc Zyngier]

On Fri, 26 Sep 2025 08:15:16 +0100,
Zhou Wang <wangzhou1@hisilicon.com> wrote:
> 
> On 2025/9/19 23:52, Marc Zyngier wrote:
> > On Mon, 01 Sep 2025 11:55:49 +0100,
> > Zhou Wang <wangzhou1@hisilicon.com> wrote:
> >>
> >> On 2025/8/25 10:39, Zhou Wang wrote:
> >>> As the discussion from V1 series, V2 series firstly adds GICD.num_LPIs
> >>> writable support, then add HiSilicon erratum 162200802.
> >>>
> >>> Erratum number should be 162200802, make a mistake in V1, so fix it as
> >>> well.
> >>>
> >>> Zhou Wang (4):
> >>>   KVM: arm64: Allow userspace to write GICD_TYPER.num_LPIs
> >>>   KVM: arm64: selftests: Add test for GICD.num_LPIs
> >>>   Documentation: KVM: arm64: Add GICD_TYPER.num_LPIs writable
> >>>     description
> >>>   ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200802
> >>
> >> Hi Marc and Oliver,
> >>
> >> As the discussion in V1 series, this series firstly adds GICD.num_LPIs
> >> writable support, then add erratum patch.
> > 
> > Given the state of this HW (as per [1]), I'd rather we start by
> > working out the strategy at the GIC level, rather than exposing stuff
> > to userspace before we agree on a way to make it work in the kernel.
> 
> This bug is in GICv4.0([1] is in GICv4.1), and seems having a clear way
> to fix. How about merging this fix firstly, then continue to try to solve [1]?

No. It has to be worked out the other way around, because this is
introducing a new userspace ABI, and adding new ABIs to cope with
design bugs is not really acceptable, specially when you have a
perfectly good way to deal with the issue (don't enable GICv4).

I also don't understand your 4.0 vs 4.1 point. This is for HIP10 and
HIP10C. [1] clearly says that both HIP9/10/10C are GICv4.1
implementations. So what is what here?

I'm mildly annoyed at being spoon-fed bits of errata with
contradicting statements instead of being given the full picture for
what looks like an implementation train-wreck. From what I can see,
these implementations are broken, and not worth salvaging. There is a
perfectly valid workaround that keeps VMs running without any extra
change. Why can't you simply use that?

Thanks,

	M.

[1] https://lore.kernel.org/r/20250909110615.129179-1-wangzhou1@hisilicon.com

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

Re: [PATCH v2 0/4] Add workaround for HIP10/HIP10C erratum 162200802

[Zhou Wang]

On 2025/9/26 16:57, Marc Zyngier wrote:
> On Fri, 26 Sep 2025 08:15:16 +0100,
> Zhou Wang <wangzhou1@hisilicon.com> wrote:
>>
>> On 2025/9/19 23:52, Marc Zyngier wrote:
>>> On Mon, 01 Sep 2025 11:55:49 +0100,
>>> Zhou Wang <wangzhou1@hisilicon.com> wrote:
>>>>
>>>> On 2025/8/25 10:39, Zhou Wang wrote:
>>>>> As the discussion from V1 series, V2 series firstly adds GICD.num_LPIs
>>>>> writable support, then add HiSilicon erratum 162200802.
>>>>>
>>>>> Erratum number should be 162200802, make a mistake in V1, so fix it as
>>>>> well.
>>>>>
>>>>> Zhou Wang (4):
>>>>>   KVM: arm64: Allow userspace to write GICD_TYPER.num_LPIs
>>>>>   KVM: arm64: selftests: Add test for GICD.num_LPIs
>>>>>   Documentation: KVM: arm64: Add GICD_TYPER.num_LPIs writable
>>>>>     description
>>>>>   ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200802
>>>>
>>>> Hi Marc and Oliver,
>>>>
>>>> As the discussion in V1 series, this series firstly adds GICD.num_LPIs
>>>> writable support, then add erratum patch.
>>>
>>> Given the state of this HW (as per [1]), I'd rather we start by
>>> working out the strategy at the GIC level, rather than exposing stuff
>>> to userspace before we agree on a way to make it work in the kernel.
>>
>> This bug is in GICv4.0([1] is in GICv4.1), and seems having a clear way
>> to fix. How about merging this fix firstly, then continue to try to solve [1]?
> 
> No. It has to be worked out the other way around, because this is
> introducing a new userspace ABI, and adding new ABIs to cope with
> design bugs is not really acceptable, specially when you have a
> perfectly good way to deal with the issue (don't enable GICv4).
> 
> I also don't understand your 4.0 vs 4.1 point. This is for HIP10 and
> HIP10C. [1] clearly says that both HIP9/10/10C are GICv4.1
> implementations. So what is what here?

HIP09/10/10C support both 4.0 and 4.1, which could be selected by a BIOS
switch.

> 
> I'm mildly annoyed at being spoon-fed bits of errata with
> contradicting statements instead of being given the full picture for
> what looks like an implementation train-wreck. From what I can see,
> these implementations are broken, and not worth salvaging. There is a
> perfectly valid workaround that keeps VMs running without any extra
> change. Why can't you simply use that?
> 
> Thanks,
> 
> 	M.
> 
> [1] https://lore.kernel.org/r/20250909110615.129179-1-wangzhou1@hisilicon.com
>