drop kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch from 4...

diff --git a/queue-4.14/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch b/queue-4.14/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch
deleted file mode 100644 (file)
index ebe429a..0000000
--- a/queue-4.14/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch
+++ /dev/null
@@ -1,67 +0,0 @@
-From james.morse@arm.com  Sat Mar 12 12:08:36 2022
-From: James Morse <james.morse@arm.com>
-Date: Tue,  8 Mar 2022 16:29:39 +0000
-Subject: KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
-To: stable@vger.kernel.org, kvmarm@lists.cs.columbia.edu
-Cc: Marc Zyngier <maz@kernel.org>, Alexandru Elisei <alexandru.elisei@arm.com>, james.morse@arm.com
-Message-ID: <20220308162939.603335-1-james.morse@arm.com>
-
-From: James Morse <james.morse@arm.com>
-
-The logic in commit 2a5f1b67ec57 "KVM: arm64: Don't access PMCR_EL0 when no
-PMU is available" relies on an empty reset handler being benign.  This was
-not the case in earlier kernel versions, so the stable backport of this
-patch is causing problems.
-
-KVMs behaviour in this area changed over time. In particular, prior to commit
-03fdfb269009 ("KVM: arm64: Don't write junk to sysregs on reset"), an empty
-reset handler will trigger a warning, as the guest registers have been
-poisoned.
-Prior to commit 20589c8cc47d ("arm/arm64: KVM: Don't panic on failure to
-properly reset system registers"), this warning was a panic().
-
-Instead of reverting the backport, make it write 0 to the sys_reg[] array.
-This keeps the reset logic happy, and the dodgy value can't be seen by
-the guest as it can't request the emulation.
-
-The original bug was accessing the PMCR_EL0 register on CPUs that don't
-implement that feature. There is no known silicon that does this, but
-v4.9's ACPI support is unable to find the PMU, so triggers this code:
-
-| Kernel panic - not syncing: Didn't reset vcpu_sys_reg(24)
-| CPU: 1 PID: 3055 Comm: lkvm Not tainted 4.9.302-00032-g64e078a56789 #13476
-| Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jul 30 2018
-| Call trace:
-| [<ffff00000808b4b0>] dump_backtrace+0x0/0x1a0
-| [<ffff00000808b664>] show_stack+0x14/0x20
-| [<ffff0000088f0e18>] dump_stack+0x98/0xb8
-| [<ffff0000088eef08>] panic+0x118/0x274
-| [<ffff0000080b50e0>] access_actlr+0x0/0x20
-| [<ffff0000080b2620>] kvm_reset_vcpu+0x5c/0xac
-| [<ffff0000080ac688>] kvm_arch_vcpu_ioctl+0x3e4/0x490
-| [<ffff0000080a382c>] kvm_vcpu_ioctl+0x5b8/0x720
-| [<ffff000008201e44>] do_vfs_ioctl+0x2f4/0x884
-| [<ffff00000820244c>] SyS_ioctl+0x78/0x9c
-| [<ffff000008083a9c>] __sys_trace_return+0x0/0x4
-
-Cc: <stable@vger.kernel.org> # < v5.3 with 2a5f1b67ec57 backported
-Signed-off-by: James Morse <james.morse@arm.com>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- arch/arm64/kvm/sys_regs.c |    4 +++-
- 1 file changed, 3 insertions(+), 1 deletion(-)
-
---- a/arch/arm64/kvm/sys_regs.c
-+++ b/arch/arm64/kvm/sys_regs.c
-@@ -471,8 +471,10 @@ static void reset_pmcr(struct kvm_vcpu *
-       u64 pmcr, val;
- 
-       /* No PMU available, PMCR_EL0 may UNDEF... */
--      if (!kvm_arm_support_pmu_v3())
-+      if (!kvm_arm_support_pmu_v3()) {
-+              vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
-               return;
-+      }
- 
-       pmcr = read_sysreg(pmcr_el0);
-       /*

diff --git a/queue-4.14/series b/queue-4.14/series
index 4f4c6002d43c3af734f2575730c5716c76bffd11..cbf40c11c0355879728e30b117ac4ba78cc7dbd4 100644 (file)
--- a/queue-4.14/series
+++ b/queue-4.14/series
@@ -15,7 +15,6 @@ tracing-ensure-trace-buffer-is-at-least-4096-bytes-l.patch
 selftests-memfd-clean-up-mapping-in-mfd_fail_write.patch
 arm-spectre-bhb-provide-empty-stub-for-non-config.patch
 staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch
-kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch
 virtio-unexport-virtio_finalize_features.patch
 virtio-acknowledge-all-features-before-access.patch
 arm-fix-thumb2-regression-with-spectre-bhb.patch

diff --git a/queue-4.19/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch b/queue-4.19/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch
deleted file mode 100644 (file)
index 08d1248..0000000
--- a/queue-4.19/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch
+++ /dev/null
@@ -1,67 +0,0 @@
-From james.morse@arm.com  Sat Mar 12 12:08:36 2022
-From: James Morse <james.morse@arm.com>
-Date: Tue,  8 Mar 2022 16:29:39 +0000
-Subject: KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
-To: stable@vger.kernel.org, kvmarm@lists.cs.columbia.edu
-Cc: Marc Zyngier <maz@kernel.org>, Alexandru Elisei <alexandru.elisei@arm.com>, james.morse@arm.com
-Message-ID: <20220308162939.603335-1-james.morse@arm.com>
-
-From: James Morse <james.morse@arm.com>
-
-The logic in commit 2a5f1b67ec57 "KVM: arm64: Don't access PMCR_EL0 when no
-PMU is available" relies on an empty reset handler being benign.  This was
-not the case in earlier kernel versions, so the stable backport of this
-patch is causing problems.
-
-KVMs behaviour in this area changed over time. In particular, prior to commit
-03fdfb269009 ("KVM: arm64: Don't write junk to sysregs on reset"), an empty
-reset handler will trigger a warning, as the guest registers have been
-poisoned.
-Prior to commit 20589c8cc47d ("arm/arm64: KVM: Don't panic on failure to
-properly reset system registers"), this warning was a panic().
-
-Instead of reverting the backport, make it write 0 to the sys_reg[] array.
-This keeps the reset logic happy, and the dodgy value can't be seen by
-the guest as it can't request the emulation.
-
-The original bug was accessing the PMCR_EL0 register on CPUs that don't
-implement that feature. There is no known silicon that does this, but
-v4.9's ACPI support is unable to find the PMU, so triggers this code:
-
-| Kernel panic - not syncing: Didn't reset vcpu_sys_reg(24)
-| CPU: 1 PID: 3055 Comm: lkvm Not tainted 4.9.302-00032-g64e078a56789 #13476
-| Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jul 30 2018
-| Call trace:
-| [<ffff00000808b4b0>] dump_backtrace+0x0/0x1a0
-| [<ffff00000808b664>] show_stack+0x14/0x20
-| [<ffff0000088f0e18>] dump_stack+0x98/0xb8
-| [<ffff0000088eef08>] panic+0x118/0x274
-| [<ffff0000080b50e0>] access_actlr+0x0/0x20
-| [<ffff0000080b2620>] kvm_reset_vcpu+0x5c/0xac
-| [<ffff0000080ac688>] kvm_arch_vcpu_ioctl+0x3e4/0x490
-| [<ffff0000080a382c>] kvm_vcpu_ioctl+0x5b8/0x720
-| [<ffff000008201e44>] do_vfs_ioctl+0x2f4/0x884
-| [<ffff00000820244c>] SyS_ioctl+0x78/0x9c
-| [<ffff000008083a9c>] __sys_trace_return+0x0/0x4
-
-Cc: <stable@vger.kernel.org> # < v5.3 with 2a5f1b67ec57 backported
-Signed-off-by: James Morse <james.morse@arm.com>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- arch/arm64/kvm/sys_regs.c |    4 +++-
- 1 file changed, 3 insertions(+), 1 deletion(-)
-
---- a/arch/arm64/kvm/sys_regs.c
-+++ b/arch/arm64/kvm/sys_regs.c
-@@ -620,8 +620,10 @@ static void reset_pmcr(struct kvm_vcpu *
-       u64 pmcr, val;
- 
-       /* No PMU available, PMCR_EL0 may UNDEF... */
--      if (!kvm_arm_support_pmu_v3())
-+      if (!kvm_arm_support_pmu_v3()) {
-+              vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
-               return;
-+      }
- 
-       pmcr = read_sysreg(pmcr_el0);
-       /*

diff --git a/queue-4.19/series b/queue-4.19/series
index e64b46688150f22e574e735d9d518f1b356db716..2a14f7b842f288b87a35633bc741312f02b5ae29 100644 (file)
--- a/queue-4.19/series
+++ b/queue-4.19/series
@@ -19,7 +19,6 @@ arm-spectre-bhb-provide-empty-stub-for-non-config.patch
 staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch
 net-macb-fix-lost-rx-packet-wakeup-race-in-napi-receive.patch
 riscv-fix-auipc-jalr-relocation-range-checks.patch
-kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch
 virtio-unexport-virtio_finalize_features.patch
 virtio-acknowledge-all-features-before-access.patch
 arm-fix-thumb2-regression-with-spectre-bhb.patch

diff --git a/queue-4.9/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch b/queue-4.9/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch
deleted file mode 100644 (file)
index 9f8d2ae..0000000
--- a/queue-4.9/kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch
+++ /dev/null
@@ -1,67 +0,0 @@
-From james.morse@arm.com  Sat Mar 12 12:08:36 2022
-From: James Morse <james.morse@arm.com>
-Date: Tue,  8 Mar 2022 16:29:39 +0000
-Subject: KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
-To: stable@vger.kernel.org, kvmarm@lists.cs.columbia.edu
-Cc: Marc Zyngier <maz@kernel.org>, Alexandru Elisei <alexandru.elisei@arm.com>, james.morse@arm.com
-Message-ID: <20220308162939.603335-1-james.morse@arm.com>
-
-From: James Morse <james.morse@arm.com>
-
-The logic in commit 2a5f1b67ec57 "KVM: arm64: Don't access PMCR_EL0 when no
-PMU is available" relies on an empty reset handler being benign.  This was
-not the case in earlier kernel versions, so the stable backport of this
-patch is causing problems.
-
-KVMs behaviour in this area changed over time. In particular, prior to commit
-03fdfb269009 ("KVM: arm64: Don't write junk to sysregs on reset"), an empty
-reset handler will trigger a warning, as the guest registers have been
-poisoned.
-Prior to commit 20589c8cc47d ("arm/arm64: KVM: Don't panic on failure to
-properly reset system registers"), this warning was a panic().
-
-Instead of reverting the backport, make it write 0 to the sys_reg[] array.
-This keeps the reset logic happy, and the dodgy value can't be seen by
-the guest as it can't request the emulation.
-
-The original bug was accessing the PMCR_EL0 register on CPUs that don't
-implement that feature. There is no known silicon that does this, but
-v4.9's ACPI support is unable to find the PMU, so triggers this code:
-
-| Kernel panic - not syncing: Didn't reset vcpu_sys_reg(24)
-| CPU: 1 PID: 3055 Comm: lkvm Not tainted 4.9.302-00032-g64e078a56789 #13476
-| Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jul 30 2018
-| Call trace:
-| [<ffff00000808b4b0>] dump_backtrace+0x0/0x1a0
-| [<ffff00000808b664>] show_stack+0x14/0x20
-| [<ffff0000088f0e18>] dump_stack+0x98/0xb8
-| [<ffff0000088eef08>] panic+0x118/0x274
-| [<ffff0000080b50e0>] access_actlr+0x0/0x20
-| [<ffff0000080b2620>] kvm_reset_vcpu+0x5c/0xac
-| [<ffff0000080ac688>] kvm_arch_vcpu_ioctl+0x3e4/0x490
-| [<ffff0000080a382c>] kvm_vcpu_ioctl+0x5b8/0x720
-| [<ffff000008201e44>] do_vfs_ioctl+0x2f4/0x884
-| [<ffff00000820244c>] SyS_ioctl+0x78/0x9c
-| [<ffff000008083a9c>] __sys_trace_return+0x0/0x4
-
-Cc: <stable@vger.kernel.org> # < v5.3 with 2a5f1b67ec57 backported
-Signed-off-by: James Morse <james.morse@arm.com>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- arch/arm64/kvm/sys_regs.c |    4 +++-
- 1 file changed, 3 insertions(+), 1 deletion(-)
-
---- a/arch/arm64/kvm/sys_regs.c
-+++ b/arch/arm64/kvm/sys_regs.c
-@@ -451,8 +451,10 @@ static void reset_pmcr(struct kvm_vcpu *
-       u64 pmcr, val;
- 
-       /* No PMU available, PMCR_EL0 may UNDEF... */
--      if (!kvm_arm_support_pmu_v3())
-+      if (!kvm_arm_support_pmu_v3()) {
-+              vcpu_sys_reg(vcpu, PMCR_EL0) = 0;
-               return;
-+      }
- 
-       pmcr = read_sysreg(pmcr_el0);
-       /*

diff --git a/queue-4.9/series b/queue-4.9/series
index 4b1e331941809aebb39d63680c8715c811b90a0c..00acd182e5250c9aa32321f8fecdc743de2f0c59 100644 (file)
--- a/queue-4.9/series
+++ b/queue-4.9/series
@@ -13,7 +13,6 @@ tracing-ensure-trace-buffer-is-at-least-4096-bytes-l.patch
 selftests-memfd-clean-up-mapping-in-mfd_fail_write.patch
 arm-spectre-bhb-provide-empty-stub-for-non-config.patch
 staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch
-kvm-arm64-reset-pmc_el0-to-avoid-a-panic-on-systems-with-no-pmu.patch
 batman-adv-request-iflink-once-in-batadv-on-batadv-check.patch
 batman-adv-don-t-expect-inter-netns-unique-iflink-indices.patch
 arm-fix-thumb2-regression-with-spectre-bhb.patch