[PATCH] KVM: arm64: Fix smp_processor_id() call in preemptible context

[Marc Zyngier]

On Tue, 06 Jun 2023 17:48:14 +0100,
Oliver Upton <oliver.upton at linux.dev> wrote:
> 
> On Tue, Jun 06, 2023 at 05:17:34PM +0100, Marc Zyngier wrote:
> > On Tue, 06 Jun 2023 15:10:44 +0100, Oliver Upton <oliver.upton at linux.dev> wrote:
> > > diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> > > index 491ca7eb2a4c..933a6331168b 100644
> > > --- a/arch/arm64/kvm/pmu-emul.c
> > > +++ b/arch/arm64/kvm/pmu-emul.c
> > > @@ -700,7 +700,7 @@ static struct arm_pmu *kvm_pmu_probe_armpmu(void)
> > >  
> > >  	mutex_lock(&arm_pmus_lock);
> > >  
> > > -	cpu = smp_processor_id();
> > > +	cpu = raw_smp_processor_id();
> > >  	list_for_each_entry(entry, &arm_pmus, entry) {
> > >  		tmp = entry->arm_pmu;
> > >  
> > > 
> > 
> > If preemption doesn't matter (and I really don't think it does), why
> > are we looking for a the current CPU? I'd rather we pick the PMU that
> > is associated with CPU0 (we're pretty sure it exists), and be done
> > with it.
> 
> Getting the current CPU is still useful, we just don't care about that
> cpu# being stale. Unconditionally using CPU0 could break existing usage
> patterns.
>
> A not-too-contrived example would be to taskset QEMU onto a cluster of
> cores in a big.LITTLE system (I do this). The current behavior would
> assign the right PMU to the guest. I've made my opinions about the 'old'
> ABI quite clear, but I don't have too great of an appetite for breakage,
> though fragile.

Fair enough.

> 
> Can we proceed with the fix I had suggested along with a more complete
> description of the baggage that we're carrying?

Sure. Please post a separate patch and I'll queue that together with
Reiji's EL0 PMU stuff for the next bag of fixes.

Thanks,

	M.

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