Repository navigation
aarch64: select the cycle counter by class, not by id - #44
Merged
Meandres merged 2 commits intoOct 22, 2026
Merged
Conversation
Two conflations of a counter id with the bitmask that selects it. pmc_stop wrote its argument into pmcntenclr_el0 as a mask, but every caller passes an id. Ids are 0..5, so id 0 cleared nothing and id 1 cleared counter 0. Harmless while counting; while sampling it leaves a counter overflowing after its handler is gone, which on a level-triggered PPI is a storm with nothing to service it. The cycle counter went the other way: it was identified by the mask 1u<<31, written as a literal in seven places, so the arch back-end recognised it by value. It does not have to. PMCSelect already knows which counter is the cycle counter -- it is the one with PMClass::CYCLES -- and that class now travels with the call, so the back-end asks what a counter *is* instead of inferring it from a magic id. The primitives therefore take a PMClass. On aarch64 it picks PMCCNTR_EL0 over PMEVCNTR<n>_EL0 and bit 31 over bit n; on x86 there is no separate cycle register, so it is accepted and ignored, and callers need no #ifdef. 31 survives once, as the documented PMCNTENSET_EL0 bit position, reached through the class rather than through an id. The cycle counter's id is now unused, so make_default_core_pmcs registers it as 0 rather than a value that means "not an id". Builds for x86-64 and aarch64. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UUfbSaGMKakCM4PxALA3vE
Collaborator
|
Why do we have PerfEvtSel and PerfCtr if that value is always the same? What does this enable us to do? |
Collaborator
Author
|
Its only the same for arm as they don't give you the hardware address of the counter but an designated assembly instruction per counter. For x86 these 2 fields hold the actual address and are therefore different. Or did I misunderstand the question? |
Master's PMU work still identified the cycle counter by the 1u<<31 id; it is ported onto this branch's PMClass-carrying primitives: - pmc_start_with_conf returns bool (master) and takes the class (this branch). The PMCCFILTR_EL0 filter write moves from the 1u<<31 evt_sel case into the CYCLES branch, and the "refuse event counters >= 6" check exempts the cycle counter by class instead of by id. - pmc_read keeps master's zero default for unwired counters. - pmc_overflow_width uses pmu_event_counter_width() for event counters and picks the cycle counter by class. - The new wrap-counting and sampler call sites, and the x86 pmc_overflow_bit stub, pass the class. - PMC::probe() is now PMC::read(), as on master. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Meandres
approved these changes
Oct 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, the cycle couter id has been hardcoded in the arm
arch-perf.hh. Basing it on the class ensures the cycle counter is whatever PMCSelect defines it to be. This however required some internal interfaces to change