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: <092db44e-f254-4abd-abea-e9a64e70df12@quicinc.com>
Date: Fri, 25 Oct 2024 19:51:22 +0530
From: Bibek Kumar Patro <quic_bibekkum@...cinc.com>
To: Will Deacon <will@...nel.org>
CC: <robdclark@...il.com>, <robin.murphy@....com>, <joro@...tes.org>,
        <jgg@...pe.ca>, <jsnitsel@...hat.com>, <robh@...nel.org>,
        <krzysztof.kozlowski@...aro.org>, <quic_c_gdjako@...cinc.com>,
        <dmitry.baryshkov@...aro.org>, <iommu@...ts.linux.dev>,
        <linux-arm-msm@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>
Subject: Re: [PATCH v16 1/5] iommu/arm-smmu: re-enable context caching in smmu
 reset operation



On 10/24/2024 6:22 PM, Will Deacon wrote:
> On Tue, Oct 08, 2024 at 06:24:06PM +0530, Bibek Kumar Patro wrote:
>> Default MMU-500 reset operation disables context caching in
>> prefetch buffer. It is however expected for context banks using
>> the ACTLR register to retain their prefetch value during reset
>> and runtime suspend.
>>
>> Replace default MMU-500 reset operation with Qualcomm specific reset
>> operation which envelope the default reset operation and re-enables
>> context caching in prefetch buffer for Qualcomm SoCs.
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum@...cinc.com>
>> ---
>>   drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 45 ++++++++++++++++++++--
>>   1 file changed, 42 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> index 087fb4f6f4d3..0cb10b354802 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> @@ -16,6 +16,16 @@
>>
>>   #define QCOM_DUMMY_VAL	-1
>>
>> +/*
>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching in the
>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the prefetch
>> + * buffer). The remaining bits are implementation defined and vary across
>> + * SoCs.
>> + */
>> +
>> +#define CPRE			(1 << 1)
>> +#define CMTLB			(1 << 0)
>> +
>>   static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
>>   {
>>   	return container_of(smmu, struct qcom_smmu, smmu);
>> @@ -396,11 +406,40 @@ static int qcom_smmu_def_domain_type(struct device *dev)
>>   	return match ? IOMMU_DOMAIN_IDENTITY : 0;
>>   }
>>
>> +static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
>> +{
>> +	int ret;
>> +	u32 val;
>> +	int i;
>> +
>> +	ret = arm_mmu500_reset(smmu);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/*
>> +	 * arm_mmu500_reset() disables CPRE which is re-enabled here.
>> +	 * The errata for MMU-500 before the r2p2 revision requires CPRE to be
>> +	 * disabled. The arm_mmu500_reset function disables CPRE to accommodate all
>> +	 * RTL revisions. Since all Qualcomm SoCs are on the r2p4 revision, where
>> +	 * the CPRE bit can be enabled, the qcom_smmu500_reset function re-enables
>> +	 * the CPRE bit for the next-page prefetcher to retain the prefetch value
>> +	 * during reset and runtime suspend operations.
>> +	 */
>> +
>> +	for (i = 0; i < smmu->num_context_banks; ++i) {
>> +		val = arm_smmu_cb_read(smmu, i, ARM_SMMU_CB_ACTLR);
>> +		val |= CPRE;
>> +		arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_ACTLR, val);
>> +	}
> 
> If CPRE only needs to be disabled prior to r2p2, then please teach the
> MMU-500 code about that instead of adding qualcomm-specific logic here.
> 

Doing this on MMU-500 code would make it generic and reflect for SoC of 
all the vendors on this platform.
We can make sure that it won't cause any problems in Qualcomm SoCs as we 
have been enabling this since for some years now and could not 
observe/reproduce any issues around these errata.

But we won't be able to guarantee the same behavior in SoC for other 
vendors where these errata might still be applicable as per [1] and [2].
So as per my understanding it's safe to include in Qualcomm specific 
implementation and not changing the default behavior in all other 
vendors' SoC even if they are not prior to r2p2 revision [3].

[1]: 
https://lore.kernel.org/all/4db1b4d2-0aa9-4640-b7d7-7d18ab64569a@arm.com/
[2]: 
https://lore.kernel.org/all/467590c40029ef0712b1fd38f2928fd4f08d09af.1726232138.git.robin.murphy@arm.com/
[3]: 
https://lore.kernel.org/all/CAA8EJprHppoN6rg8-rS1F+4kynQqmV1L3OiHFnJ0HyrshywFig@mail.gmail.com/ 


Thanks & regards,
Bibek



> Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ