On 2016-11-03 04:35, Andrew Jones wrote:
+/*
+ * Ensure that the cycle counter progresses between back-to-back
reads.
+ */
+static bool check_cycles_increase(void)
+{
+ struct pmu_data pmu = {{0}};
+
+ enable_counter(ARMV8_PMU_CYCLE_IDX);
+ set_pmccfiltr(0); /* count cycles in EL0, EL1, but not EL2 */
+
+ pmu.enable = 1;
+ set_pmcr(pmu.pmcr_el0);
+
+ for (int i = 0; i < NR_SAMPLES; i++) {
+ unsigned long a, b;
+
+ a = get_pmccntr();
+ b = get_pmccntr();
+
+ if (a >= b) {
+ printf("Read %ld then %ld.\n", a, b);
+ return false;
+ }
+ }
+
+ pmu.enable = 0;
+ set_pmcr(pmu.pmcr_el0);
+
+ return true;
+}
+
int main(void)
{
report_prefix_push("pmu");
report("Control register", check_pmcr());
+ report("Monotonically increasing cycle count",
check_cycles_increase());
return report_summary();
}
What happens with this test running on tcg? Do we just fail? Does it
explode? Is there a register we can probe and when it indicates things
won't work we can invoke a report_skip?
A monotonically increasing value (but not any attempt at approximating
actual cycle
values) in cycle counter is pretty much the only piece of the PMU it's
had implemented
for the past while. We'll have to check whether TCG can handle the
filter and enable set
registers, but if it doesn't yet, that's something we can improve :).
Thanks,
Cov
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
