linux-kernel - Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7312293d-8897-95d8-9045-9e97a6c150eb@arm.com>
Date:   Mon, 18 Dec 2017 15:39:22 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     Robin Murphy <robin.murphy@....com>,
        Linu Cherian <linuc.decode@...il.com>,
        Neil Leeder <nleeder@...eaurora.org>
Cc:     Will Deacon <will.deacon@....com>,
        Mark Rutland <mark.rutland@....com>,
        Mark Langsdorf <mlangsdo@...hat.com>,
        Jon Masters <jcm@...hat.com>,
        Timur Tabi <timur@...eaurora.org>,
        linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>,
        Mark Salter <msalter@...hat.com>,
        linux-arm-kernel@...ts.infradead.org, linu.cherian@...ium.com,
        Sunil.Goutham@...ium.com, ynorov@...iumnetworks.com
Subject: Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

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...