[PATCH] perf: arm_cspmu: Don't touch interrupt registers if no interrupt was assigned

[Ilkka Koskinen]

On Tue, 9 Apr 2024, Robin Murphy wrote:
> On 09/04/2024 2:05 am, Ilkka Koskinen wrote:
>> 
>> On Mon, 8 Apr 2024, Robin Murphy wrote:
>>> On 2024-04-05 11:33 pm, Ilkka Koskinen wrote:
>>>> 
>>>> On Fri, 5 Apr 2024, Robin Murphy wrote:
>>>>> On 2024-03-07 7:31 pm, Ilkka Koskinen wrote:
>>>>>> The driver enabled and disabled interrupts even if no interrupt was
>>>>>> assigned to the device.
>>>>> 
>>>>> Why's that a concern - if the interrupt isn't routed anywhere, surely it 
>>>>> makes no difference what happens at the source end?
>>>> 
>>>> The issue is that we have two PMUs attached to the same interrupt line.
>>>> Unfortunately, I just don't seem to find time to add support for shared 
>>>> interrupts to the cspmu driver. Meanwhile, I assigned the interrupt to 
>>>> one of the PMUs while the other one has zero in the APMT table.
>>> 
>>> I suspected something like that ;)
>>> 
>>>> Without the patch, I can trigger "ghost interrupt" in the latter PMU.
>>> 
>>> An occasional spurious interrupt should be no big deal. If it ends up as a 
>>> screaming spurious interrupt because we never handle the overflow 
>>> condition on the "other" PMU, then what matters most is that we never 
>>> handle the overflow, thus the "other" PMU is still useless since you can't 
>>> assume the user is going to read it frequently enough to avoid losing 
>>> information and getting nonsense counts back. So this hack really isn't a 
>>> viable solution for anything.
>> 
>> IIRC, what happens is that kernel will disable the interrupt eventually due 
>> to unhandled spurious interrupts making the "working" PMU also useless.
>
> Indeed, but if having one inaccurate PMU is fine, having more than one is no 
> big deal either, right? The moral of the story is that hacking the firmware 
> to lie about the hardware is just not a great idea.

Depends on the use case, of course :D

>
> TBH it's always seemed a bit broken that we allow probing without an IRQ but 
> then have no accommodation for overflow if so. Fixing that would be a good 
> thing in itself, and would at least have the side-effect of allowing your 
> hack to work, however much I may disapprove of that :)
>
> FWIW it is still lingering some way down my to-do list to factor out the 
> fiddly IRQ-sharing/migration code into at least a helper library (if not 
> further into perf core itself) before it gets copy-pasted much more, and it 
> occurs to me that I could then easily factor the IRQ-substitute timer 
> approach from e.g. arm-ccn into that as well... The more I think about it the 
> more I might just convince myself that I want it for the driver I'm currently 
> working on and justify bumping it up the list, let's see...

That sounds like a great idea. Even plain helper library would keep the 
drivers a lot cleaner.

Cheers, Ilkka