From: Andrew Murray <andrew.murray@arm.com>
To: Christoffer Dall <christoffer.dall@arm.com>,
Marc Zyngier <marc.zyngier@arm.com>
Cc: Suzuki K Pouloze <suzuki.poulose@arm.com>,
James Morse <james.morse@arm.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org,
Julien Thierry <julien.thierry@arm.com>
Subject: [PATCH v10 0/5] KVM: arm/arm64: add support for chained counters
Date: Mon, 17 Jun 2019 20:01:00 +0100 [thread overview]
Message-ID: <20190617190105.4662-1-andrew.murray@arm.com> (raw)
ARMv8 provides support for chained PMU counters, where an event type
of 0x001E is set for odd-numbered counters, the event counter will
increment by one for each overflow of the preceding even-numbered
counter. Let's emulate this in KVM by creating a 64 bit perf counter
when a user chains two emulated counters together.
Testing has been performed by hard-coding hwc->sample_period in
__hw_perf_event_init (arm_pmu.c) to a small value, this results in
regular overflows (for non sampling events). The following command
was then used to measure chained and non-chained instruction cycles:
perf stat -e armv8_pmuv3/long=1,inst_retired/u \
-e armv8_pmuv3/long=0,inst_retired/u dd if=/dev/zero bs=1M \
count=10 | gzip > /dev/null
The reported values were identical (and for non-chained was in the
same ballpark when running on a kernel without this patchset). Debug
was added to verify that the guest received overflow interrupts for
the chain counter.
The test was also repeated using the cycle counter (cycle:u).
For chained events we only support generating an overflow interrupt
on the high counter. We use the attributes of the low counter to
determine the attributes of the perf event.
Changes since v9:
- Ensure only 32 bits of cycle counter is returned when !PMCR_LC
- Add a helper to test for 64 bit counters (e.g. long cycle counter)
- Rename kvm_pmu_pmc_is_high_counter to kvm_pmu_idx_is_high_counter to
reflect arguments passed to it
Changes since v8:
- Correctly calculate the sample_period for the cycle counter
- Drop "arm64: perf: extract chain helper into header" patch
Changes since v7:
- Remove pmc->bitmask
- Remove a couple of instances of using kvm_pmu_get_canonical_pmc
when not needed
- Remove unused perf_event variable
Changes since v6:
- Drop kvm_pmu_{get,set}_perf_event
- Avoid duplicate work by using kvm_pmu_get_pair_counter_value inside
kvm_pmu_stop_counter
- Use GENMASK for 64bit mask
Changes since v5:
- Use kvm_pmu_pmc_is_high_counter instead of open coding
- Rename kvm_pmu_event_is_chained to kvm_pmu_idx_has_chain_evtype
- Use kvm_pmu_get_canonical_pmc only where needed and reintroduce
the kvm_pmu_{set, get}_perf_event functions
- Drop masking of counter in kvm_pmu_get_pair_counter_value
- Only initialise pmc once in kvm_pmu_create_perf_event and other
minor changes.
Changes since v4:
- Track pairs of chained counters with a bitmap instead of using
a struct kvm_pmc_pair.
- Rebase onto kvmarm/queue
Changes since v3:
- Simplify approach by not creating events lazily and by introducing
a struct kvm_pmc_pair to represent the relationship between
adjacent counters.
- Rebase onto v5.1-rc2
Changes since v2:
- Rebased onto v5.0-rc7
- Add check for cycle counter in correct patch
- Minor style, naming and comment changes
- Extract armv8pmu_evtype_is_chain from arch/arm64/kernel/perf_event.c
into a common header that KVM can use
Changes since v1:
- Rename kvm_pmu_{enable,disable}_counter to reflect that they can
operate on multiple counters at once and use these functions where
possible
- Fix bugs with overflow handing, kvm_pmu_get_counter_value did not
take into consideration the perf counter value overflowing the low
counter
- Ensure PMCCFILTR_EL0 is used when operating on the cycle counter
- Rename kvm_pmu_reenable_enabled_{pair, single} and similar
- Always create perf event disabled to simplify logic elsewhere
- Move PMCNTENSET_EL0 test to kvm_pmu_enable_counter_mask
Andrew Murray (5):
KVM: arm/arm64: rename kvm_pmu_{enable/disable}_counter functions
KVM: arm/arm64: extract duplicated code to own function
KVM: arm/arm64: re-create event when setting counter value
KVM: arm/arm64: remove pmc->bitmask
KVM: arm/arm64: support chained PMU counters
arch/arm64/kvm/sys_regs.c | 4 +-
include/kvm/arm_pmu.h | 11 +-
virt/kvm/arm/pmu.c | 350 ++++++++++++++++++++++++++++++--------
3 files changed, 291 insertions(+), 74 deletions(-)
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2019-06-17 19:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 19:01 Andrew Murray [this message]
2019-06-17 19:01 ` [PATCH v10 1/5] KVM: arm/arm64: rename kvm_pmu_{enable/disable}_counter functions Andrew Murray
2019-06-17 19:01 ` [PATCH v10 2/5] KVM: arm/arm64: extract duplicated code to own function Andrew Murray
2019-06-17 19:01 ` [PATCH v10 3/5] KVM: arm/arm64: re-create event when setting counter value Andrew Murray
2019-06-17 19:01 ` [PATCH v10 4/5] KVM: arm/arm64: remove pmc->bitmask Andrew Murray
2019-06-17 19:01 ` [PATCH v10 5/5] KVM: arm/arm64: support chained PMU counters Andrew Murray
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=20190617190105.4662-1-andrew.murray@arm.com \
--to=andrew.murray@arm.com \
--cc=christoffer.dall@arm.com \
--cc=james.morse@arm.com \
--cc=julien.thierry@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=suzuki.poulose@arm.com \
/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).