Re: [RFC PATCH 05/14] KVM: arm64: Always allow fixed cycle counter

[Marc Zyngier <maz@kernel.org>]

On Wed, 04 Dec 2024 21:56:58 +0000,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Wed, Dec 04, 2024 at 09:04:26AM +0000, Marc Zyngier wrote:
> > On Tue, 03 Dec 2024 22:32:38 +0000,
> > Oliver Upton <oliver.upton@linux.dev> wrote:
> > > > More importantly, the current filtering works in terms of events, and
> > > > not in terms of counters.
> > > > 
> > > > Instead of changing the ABI, how about simply not supporting filtering
> > > > on such non-compliant HW? Surely that would simplify a few things.
> > > 
> > > Yeah, that sounds reasonable. Especially if we allow programmable event
> > > counters where the event ID space doesn't match the architecture.
> > 
> > Another thing I have been wondering is if a slightly better approach
> > would be to move some of the handling to the PMU driver itself, and
> > let it emulate PMUv3 if it can. This would allow conversion of event
> > numbers in situ rather than polluting the PMUv3 code in KVM.
> 
> Sure, but I think the actual event fed into perf_event_create_kernel_counter()
> should be the correct hardware event, not a PMUv3 event reinterpreted
> behind the scenes. Otherwise, we'd need to devise an alternate config encoding
> for PMUv3-like events since the event ID spaces overlap.
> 
> I'm thinking this could be a helper in the arm_pmu struct that takes a
> PMUv3 event and spits out (in this case) an M1 event. The resulting KVM
> code would be miniscule, like:
> 
> u64 kvm_map_pmu_event(struct kvm *kvm, u64 eventsel)
> {
> 	struct arm_pmu *pmu = kvm->arch.arm_pmu;
> 
> 	if (!pmu->map_pmuv3_event)
> 		return eventsel;
> 
> 	return pmu->map_pmuv3_event(eventsel);
> }
> 
> static void kvm_pmu_create_perf_event(struct kvm_pmc *pmc)
> {
> 
> 	[...]
> 
> 	attr.config = kvm_map_pmu_event(vcpu->kvm, eventsel);
> 	event = perf_event_create_kernel_counter(&attr, ...);
> }
> 
> We could even have the M1 PMU driver populate arm_pmu->pmceid_bitmap
> with the events it knows about and get PMCEID emulation for free.

CONFIG_PMUv3_COMPAT? ;-)

I think this is probably the less intrusive thing to do for KVM
(outside of the butt-ugly trap decoding thingy), and it squarely puts
the responsibility on the PMU driver to expose something that makes
sense in a given context.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.