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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <86wmg7sw9a.wl-maz@kernel.org>
Date: Tue, 10 Dec 2024 09:49:37 +0000
From: Marc Zyngier <maz@...nel.org>
To: Oliver Upton <oliver.upton@...ux.dev>
Cc: kvmarm@...ts.linux.dev,
	Joey Gouly <joey.gouly@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	Mingwei Zhang <mizhang@...gle.com>,
	Colton Lewis <coltonlewis@...gle.com>,
	Raghavendra Rao Ananta <rananta@...gle.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 05/14] KVM: arm64: Always allow fixed cycle counter

On Wed, 04 Dec 2024 21:56:58 +0000,
Oliver Upton <oliver.upton@...ux.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@...ux.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.