|author||Vladimir Murzin <firstname.lastname@example.org>||2016-08-10 10:49:42 +0100|
|committer||Christoffer Dall <email@example.com>||2016-08-17 12:46:21 +0200|
|parent||KVM: arm/arm64: timer: Workaround misconfigured timer interrupt (diff)|
arm64: KVM: remove misleading comment on pmu status
Comment about how PMU access is handled is not relavant since v4.6 where proper PMU support was added in. Signed-off-by: Vladimir Murzin <firstname.lastname@example.org> Acked-by: Marc Zyngier <email@example.com> Signed-off-by: Christoffer Dall <firstname.lastname@example.org>
Diffstat (limited to 'arch/arm64/kvm')
1 files changed, 0 insertions, 8 deletions
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index b0b225ceca18..af5ea86d1c19 100644
@@ -823,14 +823,6 @@ static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
* Architected system registers.
* Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
- * We could trap ID_DFR0 and tell the guest we don't support performance
- * monitoring. Unfortunately the patch to make the kernel check ID_DFR0 was
- * NAKed, so it will read the PMCR anyway.
- * Therefore we tell the guest we have 0 counters. Unfortunately, we
- * must always support PMCCNTR (the cycle counter): we just RAZ/WI for
- * all PM registers, which doesn't crash the guest kernel at least.
* Debug handling: We do trap most, if not all debug related system
* registers. The implementation is good enough to ensure that a guest
* can use these with minimal performance degradation. The drawback is