lkml.org 
[lkml]   [2017]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
From
Date
Thanks for putting me in the loop Robin.

On 18/12/17 14:48, Robin Murphy wrote:
> On 10/12/17 02:35, Linu Cherian wrote:
>> Hi,
>>
>>
>> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote:
>>> This adds a driver for the SMMUv3 PMU into the perf framework.
>>> It includes an IORT update to support PM Counter Groups.
>>>
>>
>> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way
>> that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU.
>> This would be a matter of concern for software if the SMMU and SMMU PMCG blocks
>> are managed by two independent drivers.
>>
>> The problem arises when we want to alloc/free MSIs for these devices
>> using the APIs, platform_msi_domain_alloc/free_irqs.
>> Platform bus id being same for these two hardware blocks, they end up sharing the same
>> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management
>> of this shared ITT becomes a problem when they are managed by two independent
>> drivers.
>
> What is the problem exactly? IIRC resizing a possibly-live ITT is a
> right pain in the bum to do - is it just that?

Understatement of the day! ;-) Yes, it is a massive headache, and will
either result in a temporary loss of interrupts (at some point you have
to unmap the ITT), or with spurious interrupts (you generate interrupts
for all the MSIs you've blackholed when unmapping the ITT).

>
>> We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under
>> SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors
>> required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs
>> function call for all devices that share the platform bus id.
>
> I'm not sure how scalable that approach would be, since it's not
> entirely obvious how to handle PMCGs associated with named components or
> root complexes (rather than directly with SMMU instances). We certainly
> don't want to end up spraying similar PMCG DevID logic around all manner
> of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs
> will be expected to have distinct IDs from their host devices, they
> could reasonably still overlap with other PMCGs/SMMUs).
>
>> Would like to know your expert opinion on what would be the right approach
>> to handle this case ?
>
> My gut feeling says the way to deal with this properly is in the ITS
> code, but I appreciate that that's a lot easier said than done :/

I can revive the hack I once wrote for that (and that was hoping to
forever forget), but that's pretty disgusting, and subject to the above
caveat.

Thanks,

M.
--
Jazz is not dead. It just smells funny...

\
 
 \ /
  Last update: 2017-12-18 16:40    [W:0.074 / U:4.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site