From: Eric Auger <eric.auger@redhat.com>
To: eric.auger.pro@gmail.com, eric.auger@redhat.com,
kvm@vger.kernel.org, kvmarm@lists.linux.dev,
andrew.jones@linux.dev, maz@kernel.org, oliver.upton@linux.dev,
alexandru.elisei@arm.com
Cc: jarichte@redhat.com
Subject: [kvm-unit-tests PATCH] arm: pmu-overflow-interrupt: Increase count values
Date: Fri, 3 Nov 2023 11:01:39 +0100 [thread overview]
Message-ID: <20231103100139.55807-1-eric.auger@redhat.com> (raw)
On some hardware, some pmu-overflow-interrupt failures can be observed.
Although the even counter overflows, the interrupt is not seen as
expected. This happens in the subtest after "promote to 64-b" comment.
After analysis, the PMU overflow interrupt actually hits, ie.
kvm_pmu_perf_overflow() gets called and KVM_REQ_IRQ_PENDING is set,
as expected. However the PMCR.E is reset by the handle_exit path, at
kvm_pmu_handle_pmcr() before the next guest entry and
kvm_pmu_flush_hwstate/kvm_pmu_update_state subsequent call.
There, since the enable bit has been reset, kvm_pmu_update_state() does
not inject the interrupt into the guest.
This does not seem to be a KVM bug but rather an unfortunate
scenario where the test disables the PMCR.E too closely to the
advent of the overflow interrupt.
Since it looks like a benign and inlikely case, let's resize the number
of iterations to prevent the PMCR enable bit from being resetted
at the same time as the actual overflow event.
COUNT_INT is introduced, arbitrarily set to 1000 iterations and is
used in this test.
Reported-by: Jan Richter <jarichte@redhat.com>
Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
arm/pmu.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arm/pmu.c b/arm/pmu.c
index a91a7b1f..acd88571 100644
--- a/arm/pmu.c
+++ b/arm/pmu.c
@@ -66,6 +66,7 @@
#define PRE_OVERFLOW_64 0xFFFFFFFFFFFFFFF0ULL
#define COUNT 250
#define MARGIN 100
+#define COUNT_INT 1000
/*
* PRE_OVERFLOW2 is set so that 1st @COUNT iterations do not
* produce 32b overflow and 2nd @COUNT iterations do. To accommodate
@@ -978,13 +979,13 @@ static void test_overflow_interrupt(bool overflow_at_64bits)
/* interrupts are disabled (PMINTENSET_EL1 == 0) */
- mem_access_loop(addr, 200, pmu.pmcr_ro | PMU_PMCR_E | pmcr_lp);
+ mem_access_loop(addr, COUNT_INT, pmu.pmcr_ro | PMU_PMCR_E | pmcr_lp);
report(expect_interrupts(0), "no overflow interrupt after preset");
set_pmcr(pmu.pmcr_ro | PMU_PMCR_E | pmcr_lp);
isb();
- for (i = 0; i < 100; i++)
+ for (i = 0; i < COUNT_INT; i++)
write_sysreg(0x2, pmswinc_el0);
isb();
@@ -1002,15 +1003,15 @@ static void test_overflow_interrupt(bool overflow_at_64bits)
write_sysreg(ALL_SET_32, pmintenset_el1);
isb();
- mem_access_loop(addr, 200, pmu.pmcr_ro | PMU_PMCR_E | pmcr_lp);
+ mem_access_loop(addr, COUNT_INT, pmu.pmcr_ro | PMU_PMCR_E | pmcr_lp);
set_pmcr(pmu.pmcr_ro | PMU_PMCR_E | pmcr_lp);
isb();
- for (i = 0; i < 100; i++)
+ for (i = 0; i < COUNT_INT; i++)
write_sysreg(0x3, pmswinc_el0);
- mem_access_loop(addr, 200, pmu.pmcr_ro);
+ mem_access_loop(addr, COUNT_INT, pmu.pmcr_ro);
report_info("overflow=0x%lx", read_sysreg(pmovsclr_el0));
report(expect_interrupts(0x3),
"overflow interrupts expected on #0 and #1");
@@ -1029,7 +1030,7 @@ static void test_overflow_interrupt(bool overflow_at_64bits)
write_regn_el0(pmevtyper, 1, CHAIN | PMEVTYPER_EXCLUDE_EL0);
write_regn_el0(pmevcntr, 0, pre_overflow);
isb();
- mem_access_loop(addr, 200, pmu.pmcr_ro | PMU_PMCR_E | pmcr_lp);
+ mem_access_loop(addr, COUNT_INT, pmu.pmcr_ro | PMU_PMCR_E | pmcr_lp);
report(expect_interrupts(0x1), "expect overflow interrupt");
/* overflow on odd counter */
@@ -1037,7 +1038,7 @@ static void test_overflow_interrupt(bool overflow_at_64bits)
write_regn_el0(pmevcntr, 0, pre_overflow);
write_regn_el0(pmevcntr, 1, all_set);
isb();
- mem_access_loop(addr, 400, pmu.pmcr_ro | PMU_PMCR_E | pmcr_lp);
+ mem_access_loop(addr, COUNT_INT, pmu.pmcr_ro | PMU_PMCR_E | pmcr_lp);
if (overflow_at_64bits) {
report(expect_interrupts(0x1),
"expect overflow interrupt on even counter");
--
2.41.0
next reply other threads:[~2023-11-03 10:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 10:01 Eric Auger [this message]
2023-11-07 9:52 ` [kvm-unit-tests PATCH] arm: pmu-overflow-interrupt: Increase count values Alexandru Elisei
2023-11-07 13:34 ` Eric Auger
2023-11-07 14:05 ` Alexandru Elisei
2023-11-07 14:28 ` Eric Auger
2023-11-07 15:29 ` Alexandru Elisei
2023-11-13 17:43 ` Eric Auger
2023-11-08 6:21 ` Andrew Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231103100139.55807-1-eric.auger@redhat.com \
--to=eric.auger@redhat.com \
--cc=alexandru.elisei@arm.com \
--cc=andrew.jones@linux.dev \
--cc=eric.auger.pro@gmail.com \
--cc=jarichte@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox