The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 54bbee190d42166209185d89070c58a343bf514b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to 'stable@vger.kernel.org' --in-reply-to '2024120223-stunner-letter-9d09@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 54bbee190d42166209185d89070c58a343bf514b Mon Sep 17 00:00:00 2001 From: Raghavendra Rao Ananta rananta@google.com Date: Tue, 19 Nov 2024 16:52:29 -0800 Subject: [PATCH] KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status
DDI0487K.a D13.3.1 describes the PMU overflow condition, which evaluates to true if any counter's global enable (PMCR_EL0.E), overflow flag (PMOVSSET_EL0[n]), and interrupt enable (PMINTENSET_EL1[n]) are all 1. Of note, this does not require a counter to be enabled (i.e. PMCNTENSET_EL0[n] = 1) to generate an overflow.
Align kvm_pmu_overflow_status() with the reality of the architecture and stop using PMCNTENSET_EL0 as part of the overflow condition. The bug was discovered while running an SBSA PMU test [*], which only sets PMCR.E, PMOVSSET<0>, PMINTENSET<0>, and expects an overflow interrupt.
Cc: stable@vger.kernel.org Fixes: 76d883c4e640 ("arm64: KVM: Add access handler for PMOVSSET and PMOVSCLR register") Link: https://github.com/ARM-software/sbsa-acs/blob/master/test_pool/pmu/operating... Signed-off-by: Raghavendra Rao Ananta rananta@google.com [ oliver: massaged changelog ] Reviewed-by: Marc Zyngier maz@kernel.org Link: https://lore.kernel.org/r/20241120005230.2335682-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton oliver.upton@linux.dev
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c index 8ad62284fa23..3855cc9d0ca5 100644 --- a/arch/arm64/kvm/pmu-emul.c +++ b/arch/arm64/kvm/pmu-emul.c @@ -381,7 +381,6 @@ static u64 kvm_pmu_overflow_status(struct kvm_vcpu *vcpu)
if ((kvm_vcpu_read_pmcr(vcpu) & ARMV8_PMU_PMCR_E)) { reg = __vcpu_sys_reg(vcpu, PMOVSSET_EL0); - reg &= __vcpu_sys_reg(vcpu, PMCNTENSET_EL0); reg &= __vcpu_sys_reg(vcpu, PMINTENSET_EL1); }
commit 54bbee190d42166209185d89070c58a343bf514b upstream.
DDI0487K.a D13.3.1 describes the PMU overflow condition, which evaluates to true if any counter's global enable (PMCR_EL0.E), overflow flag (PMOVSSET_EL0[n]), and interrupt enable (PMINTENSET_EL1[n]) are all 1. Of note, this does not require a counter to be enabled (i.e. PMCNTENSET_EL0[n] = 1) to generate an overflow.
Align kvm_pmu_overflow_status() with the reality of the architecture and stop using PMCNTENSET_EL0 as part of the overflow condition. The bug was discovered while running an SBSA PMU test [*], which only sets PMCR.E, PMOVSSET<0>, PMINTENSET<0>, and expects an overflow interrupt.
Cc: stable@vger.kernel.org Fixes: 76d883c4e640 ("arm64: KVM: Add access handler for PMOVSSET and PMOVSCLR register") Link: https://github.com/ARM-software/sbsa-acs/blob/master/test_pool/pmu/operating... Signed-off-by: Raghavendra Rao Ananta rananta@google.com [ oliver: massaged changelog ] Reviewed-by: Marc Zyngier maz@kernel.org Link: https://lore.kernel.org/r/20241120005230.2335682-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton oliver.upton@linux.dev --- virt/kvm/arm/pmu.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c index 6d52fd50c1ff..b92b1d406374 100644 --- a/virt/kvm/arm/pmu.c +++ b/virt/kvm/arm/pmu.c @@ -195,7 +195,6 @@ static u64 kvm_pmu_overflow_status(struct kvm_vcpu *vcpu)
if ((__vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E)) { reg = __vcpu_sys_reg(vcpu, PMOVSSET_EL0); - reg &= __vcpu_sys_reg(vcpu, PMCNTENSET_EL0); reg &= __vcpu_sys_reg(vcpu, PMINTENSET_EL1); reg &= kvm_pmu_valid_counter_mask(vcpu); }
[ Sasha's backport helper bot ]
Hi,
The upstream commit SHA1 provided is correct: 54bbee190d42166209185d89070c58a343bf514b
Status in newer kernel trees: 6.12.y | Present (different SHA1: 2a68705a5469)
Note: The patch differs from the upstream commit: --- Failed to apply patch cleanly, falling back to interdiff... ---
Results of testing on various branches:
| Branch | Patch Apply | Build Test | |---------------------------|-------------|------------| | stable/linux-6.12.y | Failed | N/A | | stable/linux-6.11.y | Failed | N/A | | stable/linux-6.6.y | Failed | N/A | | stable/linux-6.1.y | Failed | N/A | | stable/linux-5.15.y | Failed | N/A | | stable/linux-5.10.y | Failed | N/A | | stable/linux-5.4.y | Success | Success | | stable/linux-4.19.y | Success | Success |
On Tue, Dec 03, 2024 at 07:02:36PM +0000, Raghavendra Rao Ananta wrote:
commit 54bbee190d42166209185d89070c58a343bf514b upstream.
DDI0487K.a D13.3.1 describes the PMU overflow condition, which evaluates to true if any counter's global enable (PMCR_EL0.E), overflow flag (PMOVSSET_EL0[n]), and interrupt enable (PMINTENSET_EL1[n]) are all 1. Of note, this does not require a counter to be enabled (i.e. PMCNTENSET_EL0[n] = 1) to generate an overflow.
Align kvm_pmu_overflow_status() with the reality of the architecture and stop using PMCNTENSET_EL0 as part of the overflow condition. The bug was discovered while running an SBSA PMU test [*], which only sets PMCR.E, PMOVSSET<0>, PMINTENSET<0>, and expects an overflow interrupt.
Cc: stable@vger.kernel.org Fixes: 76d883c4e640 ("arm64: KVM: Add access handler for PMOVSSET and PMOVSCLR register") Link: https://github.com/ARM-software/sbsa-acs/blob/master/test_pool/pmu/operating... Signed-off-by: Raghavendra Rao Ananta rananta@google.com [ oliver: massaged changelog ] Reviewed-by: Marc Zyngier maz@kernel.org Link: https://lore.kernel.org/r/20241120005230.2335682-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton oliver.upton@linux.dev
virt/kvm/arm/pmu.c | 1 - 1 file changed, 1 deletion(-)
What branch is this patch for?
thanks,
greg k-h
On Tue, Dec 03, 2024 at 07:02:36PM +0000, Raghavendra Rao Ananta wrote:
commit 54bbee190d42166209185d89070c58a343bf514b upstream.
DDI0487K.a D13.3.1 describes the PMU overflow condition, which evaluates to true if any counter's global enable (PMCR_EL0.E), overflow flag (PMOVSSET_EL0[n]), and interrupt enable (PMINTENSET_EL1[n]) are all 1. Of note, this does not require a counter to be enabled (i.e. PMCNTENSET_EL0[n] = 1) to generate an overflow.
Align kvm_pmu_overflow_status() with the reality of the architecture and stop using PMCNTENSET_EL0 as part of the overflow condition. The bug was discovered while running an SBSA PMU test [*], which only sets PMCR.E, PMOVSSET<0>, PMINTENSET<0>, and expects an overflow interrupt.
Cc: stable@vger.kernel.org Fixes: 76d883c4e640 ("arm64: KVM: Add access handler for PMOVSSET and PMOVSCLR register") Link: https://github.com/ARM-software/sbsa-acs/blob/master/test_pool/pmu/operating... Signed-off-by: Raghavendra Rao Ananta rananta@google.com [ oliver: massaged changelog ] Reviewed-by: Marc Zyngier maz@kernel.org Link: https://lore.kernel.org/r/20241120005230.2335682-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton oliver.upton@linux.dev
virt/kvm/arm/pmu.c | 1 - 1 file changed, 1 deletion(-)
What kernel branch(es) is this backport for?
Hi Greg,
This is an adjustment of the original upstream patch aimed towards the 4.19.y stable branch.
Thank you. Raghavendra
On Thu, Dec 12, 2024 at 12:27 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Dec 03, 2024 at 07:02:36PM +0000, Raghavendra Rao Ananta wrote:
commit 54bbee190d42166209185d89070c58a343bf514b upstream.
DDI0487K.a D13.3.1 describes the PMU overflow condition, which evaluates to true if any counter's global enable (PMCR_EL0.E), overflow flag (PMOVSSET_EL0[n]), and interrupt enable (PMINTENSET_EL1[n]) are all 1. Of note, this does not require a counter to be enabled (i.e. PMCNTENSET_EL0[n] = 1) to generate an overflow.
Align kvm_pmu_overflow_status() with the reality of the architecture and stop using PMCNTENSET_EL0 as part of the overflow condition. The bug was discovered while running an SBSA PMU test [*], which only sets PMCR.E, PMOVSSET<0>, PMINTENSET<0>, and expects an overflow interrupt.
Cc: stable@vger.kernel.org Fixes: 76d883c4e640 ("arm64: KVM: Add access handler for PMOVSSET and PMOVSCLR register") Link: https://github.com/ARM-software/sbsa-acs/blob/master/test_pool/pmu/operating... Signed-off-by: Raghavendra Rao Ananta rananta@google.com [ oliver: massaged changelog ] Reviewed-by: Marc Zyngier maz@kernel.org Link: https://lore.kernel.org/r/20241120005230.2335682-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton oliver.upton@linux.dev
virt/kvm/arm/pmu.c | 1 - 1 file changed, 1 deletion(-)
What kernel branch(es) is this backport for?
On Thu, Dec 12, 2024 at 09:41:28AM -0800, Raghavendra Rao Ananta wrote:
Hi Greg,
This is an adjustment of the original upstream patch aimed towards the 4.19.y stable branch.
4.19.y is end-of-life, so there's nothing we can do there. But what about 5.4.y? If it matters there, please resend it in a format we can apply it in for that tree.
thanks,
greg k-h
On Thu, Dec 12, 2024 at 10:07 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Dec 12, 2024 at 09:41:28AM -0800, Raghavendra Rao Ananta wrote:
Hi Greg,
This is an adjustment of the original upstream patch aimed towards the 4.19.y stable branch.
4.19.y is end-of-life, so there's nothing we can do there. But what about 5.4.y? If it matters there, please resend it in a format we can apply it in for that tree.
The version of the patch from this thread applies to 5.4.y as well. Do you want me to resend it or will you be able to pick this up?
Thank you. Raghavendra
Raghavendra
On Thu, Dec 12, 2024 at 10:52:07AM -0800, Raghavendra Rao Ananta wrote:
On Thu, Dec 12, 2024 at 10:07 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Dec 12, 2024 at 09:41:28AM -0800, Raghavendra Rao Ananta wrote:
Hi Greg,
This is an adjustment of the original upstream patch aimed towards the 4.19.y stable branch.
4.19.y is end-of-life, so there's nothing we can do there. But what about 5.4.y? If it matters there, please resend it in a format we can apply it in for that tree.
The version of the patch from this thread applies to 5.4.y as well. Do you want me to resend it or will you be able to pick this up?
Please resend it.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org