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]
Date:   Wed, 5 Sep 2018 14:52:21 +0530
From:   Vivek Gautam <vivek.gautam@...eaurora.org>
To:     Will Deacon <will.deacon@....com>, robdclark@...il.com
Cc:     joro@...tes.org, andy.gross@...aro.org, robin.murphy@....com,
        bjorn.andersson@...aro.org, iommu@...ts.linux-foundation.org,
        mark.rutland@....com, david.brown@...aro.org, tfiga@...omium.org,
        swboyd@...omium.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/5] Qcom smmu-500 TLB invalidation errata for sdm845


On 8/14/2018 5:54 PM, Vivek Gautam wrote:
> Hi Will,
>
>
> On 8/14/2018 5:10 PM, Will Deacon wrote:
>> Hi Vivek,
>>
>> On Tue, Aug 14, 2018 at 04:25:23PM +0530, Vivek Gautam wrote:
>>> Qcom's implementation of arm,mmu-500 on sdm845 has a 
>>> functional/performance
>>> errata [1] because of which the TCU cache look ups are stalled during
>>> invalidation cycle. This is mitigated by serializing all the 
>>> invalidation
>>> requests coming to the smmu.
>> How does this implementation differ from the one supported by 
>> qcom_iommu.c?
>> I notice you're adding firmware hooks here, which we avoided by 
>> having the
>> extra driver. Please help me understand which devices exist, how they
>> differ, and which drivers are intended to support them!
>
> IIRC, the qcom_iommu driver was intended to support the static context 
> bank - SID
> mapping, and is very specific to the smmu-v2 version present on 
> msm8916 soc.
> However, this is the qcom's mmu-500 implementation specific errata. 
> qcom_iommu
> will not be able to support mmu-500 configurations.
> Rob Clark can add more.
> Let you know what you suggest.

Rob, can you please comment about how qcom-smmu driver has different 
implementation
from arm-smmu driver?
Will, in case we would want to use arm-smmu driver, what would you 
suggest for
having the firmware hooks?
Thanks.

Best regards
Vivek
>
>>
>> Also -- you didn't CC all the maintainers for the firmware bits, so 
>> adding
>> Andy here for that, and Rob for the previous question.
>
> I added Andy to the series, would you want me to add Rob H also?
>
> Best regards
> Vivek
>
>>
>> Thanks,
>>
>> Will
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ