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 v2 2/2] arm: pmu-overflow-interrupt: Increase count values
Date: Mon, 13 Nov 2023 18:42:41 +0100 [thread overview]
Message-ID: <20231113174316.341630-3-eric.auger@redhat.com> (raw)
In-Reply-To: <20231113174316.341630-1-eric.auger@redhat.com>
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
immediately at the same time as the actual overflow event.
COUNT_INT is introduced, arbitrarily set to 1000 iterations and is
used in this test.
An alternative would be to let the PMU enabled and wait for the
interrupt but those extra executions might disturb the counting.
Reported-by: Jan Richter <jarichte@redhat.com>
Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
v1 -> v2:
- Only increase mem_access_loop iterations
---
arm/pmu.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arm/pmu.c b/arm/pmu.c
index 86199577..4b388899 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,7 +979,7 @@ 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);
@@ -1002,7 +1003,7 @@ 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();
@@ -1010,7 +1011,7 @@ static void test_overflow_interrupt(bool overflow_at_64bits)
for (i = 0; i < 100; 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 prev parent reply other threads:[~2023-11-13 17:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 17:42 [kvm-unit-tests PATCH v2 0/2] arm: pmu-overflow-interrupt: Fix failures on Amberwing Eric Auger
2023-11-13 17:42 ` [kvm-unit-tests PATCH v2 1/2] arm: pmu: Declare pmu_stats as volatile Eric Auger
2023-11-14 3:08 ` Shaoqin Huang
2023-11-20 17:28 ` Alexandru Elisei
2023-11-13 17:42 ` Eric Auger [this message]
2023-11-14 3:09 ` [kvm-unit-tests PATCH v2 2/2] arm: pmu-overflow-interrupt: Increase count values Shaoqin Huang
2023-11-21 11:45 ` [kvm-unit-tests PATCH v2 0/2] arm: pmu-overflow-interrupt: Fix failures on Amberwing 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=20231113174316.341630-3-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;
as well as URLs for NNTP newsgroup(s).