Received-SPF: pass (google.com: domain of linux-kernel+bounces-123768-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: "Maulik Shah (mkshah)" <quic_mkshah@quicinc.com>
CC: Caleb Connolly <caleb.connolly@linaro.org>,
        "andersson@kernel.org >> Bjorn
 Andersson" <andersson@kernel.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        LKML
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] soc: qcom: cmd-db: map shared memory as WT, not WB
Thread-Topic: [PATCH] soc: qcom: cmd-db: map shared memory as WT, not WB
Thread-Index: AQHagIKviCrPH112HEOpsjr5BCtYWLFNDjIAgACrjAA=
Date: Thu, 28 Mar 2024 22:19:04 +0000
Message-ID: <87sf0axanc.fsf@epam.com>
References: <20240327200917.2576034-1-volodymyr_babchuk@epam.com>
 <19bb6ff0-04ff-4e88-8c8a-499c054bdea4@quicinc.com>
In-Reply-To: <19bb6ff0-04ff-4e88-8c8a-499c054bdea4@quicinc.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: mu4e 1.10.7; emacs 29.1
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?iso-8859-1?Q?grGXhM/5dwhvik554sRYi6Jqu3MU7QIaxhTZvw0Z4LRh8EYr9e0thgNjFn?=
 =?iso-8859-1?Q?g6QyWnDhhQ6h3KvdMoSdIN77mP3TnRDV855POUDXFRBRU5dUFt2jXiotzh?=
 =?iso-8859-1?Q?M9WPxzDsckM4OF5HsrfeU3+FtTiiqE2of3ZGxyrtsLssZsEFyJNtbh3Fqy?=
 =?iso-8859-1?Q?CrB+LhkaJMSqjrSAb7TqbLyQTOujqwc04FgNa74ej0Lfxmyel8NZ8/mTpX?=
 =?iso-8859-1?Q?N6pzFr7Qp7uZjBYYb3910MDXjmBv/Yvs9X4h/TZXDfXLIJshHrvoHUH3S3?=
 =?iso-8859-1?Q?5muiAILD48AShc6W3YZ/8x4qUfU1XE1VaKua1tRUHIZ1nhTqKE+NJSBldQ?=
 =?iso-8859-1?Q?Bsm1jO/OxVx5dvig7Wuuc+onZCR44lq7VQ7hGt4U+hNKNdBxy/t2w2c/Oy?=
 =?iso-8859-1?Q?Gi3FrjTQBB2Ym0pMOGBtZAwuswae/iMMHQ7aNkmxHTspAcUjXsu/L7kqnC?=
 =?iso-8859-1?Q?cWRG8V9+d3C3me7d+szjVg6hDj1T2BYR04pbwegDHkX/ac2xqXvKgNBBgR?=
 =?iso-8859-1?Q?he7m1cNWXD4Xg8/EM7Sa/0hRxFsjiXFODSQaL3JQWP+0xBOiT86StI3QOl?=
 =?iso-8859-1?Q?6lA5gIBY5uOFT7vuqC6Jf57ZgeQTJEIjw3W8uNLYYtUgDyfCxCWZgWEcye?=
 =?iso-8859-1?Q?U64KoFDIog6SzuG5xiTLjpJsGYwcsL96XNJ7h1ryeoq+P8vuOkj/U7uZr5?=
 =?iso-8859-1?Q?GjsDoI4oVjl9rGrZzxX4eMZ3uGriUJ2tr8Ptxp8Aj3InXmiaY1EMXGnZ+g?=
 =?iso-8859-1?Q?A0GQaSFNMbCqARRA0bIq/lPjEqY+VCAj6itnJvdPoSMv2fsM49WKDHEmQB?=
 =?iso-8859-1?Q?bgdC7ARQ0vuZKLP0+bx3VE0SE65UumACYBtm0aNResj89EdF4/0beW/w8A?=
 =?iso-8859-1?Q?UfiqEyWWSjWpfGGuFQb6/7OkspWK7bGwPJXGYjyHtmo5nQ0PSvd3zh193g?=
 =?iso-8859-1?Q?uLmxVHV9Hyw1LREGpCh5e82otcJo76VmfPj6Hv/4ddDG2OwhKHGmUSZ3Cy?=
 =?iso-8859-1?Q?jXxpMRpPlIBaMyFJTHiqvv1+Q7uPGfkdD4Om5jswUnb5B8TRF71rmRdVUr?=
 =?iso-8859-1?Q?XGQi4GYScspzfAyB7zZqTeg06a9mWywXwKjbiCQkCTgCuGTpmwG3ob5yh3?=
 =?iso-8859-1?Q?JPrn5UZbyKLqQgpGC+9nEM60UKpkTxXPIEXV1lbr6hGYe5cJjO/Sj53cIT?=
 =?iso-8859-1?Q?sy3JXPQn9AmEq3klXcMu+fntFEVE+0v2BA0TfrFvqnd06W3QSQ4v09+HOB?=
 =?iso-8859-1?Q?KW63uv7JbpKhz7xjhGSjcpkz6sGGaHskjVgwzmAI5tNT7QitF8djMeg9RK?=
 =?iso-8859-1?Q?ph4n6vUFMGn1IxUwik3RhGDGt1UWmlfEqwzlGfBP/ycFhYCdw2z0jbREWI?=
 =?iso-8859-1?Q?20vdYqfqmFPbWLK2PAzIJ8TmVjkAlrxLZ08CrZzEuclJKxQBstqEUhFRij?=
 =?iso-8859-1?Q?e0lsIRATDwG07JRTlxixJq3ID2ZR+1sgq/uezzUYZQw4KmfIev8v2b2lyh?=
 =?iso-8859-1?Q?w1EPYEfdq/wNyTX6J9zFX/25auG9tHkofMBuipa7CJmu+/Xafm1vV39hgH?=
 =?iso-8859-1?Q?uiArAifkaHdoXUYqD6yAR90YXfxLBiGePgoyRZqBpJa/7GUya4BNKj8xDb?=
 =?iso-8859-1?Q?1Td/0O1hRqV4TmW9BfoKFH7cMKfwaFDWzdVWT2fuI9WS7PYIux/O7hFw?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a17adbd-25a4-4bdf-0953-08dc4f751411
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2024 22:19:04.5561
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kmgUyyBr0uzXN7btOUsG2+sQZij5+GuS4WgC8IAR/Xm68GGG4fW3Iskx3CpHAq16DCH5ZQeowH4eLAdi80VqevSr6wuodigmu30/yxAI6xM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA6PR03MB10324
X-Proofpoint-ORIG-GUID: cvknSzd17QgfbkyhKb_hR-t6rfkx83t4
X-Proofpoint-GUID: cvknSzd17QgfbkyhKb_hR-t6rfkx83t4
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-28_17,2024-03-28_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxscore=0
 impostorscore=0 adultscore=0 bulkscore=0 lowpriorityscore=0 malwarescore=0
 clxscore=1011 mlxlogscore=999 phishscore=0 suspectscore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2403210001
 definitions=main-2403280160


Hi Maulik

"Maulik Shah (mkshah)" <quic_mkshah@quicinc.com> writes:

> On 3/28/2024 1:39 AM, Volodymyr Babchuk wrote:
>> It appears that hardware does not like cacheable accesses to this
>> region. Trying to access this shared memory region as Normal Memory
>> leads to secure interrupt which causes an endless loop somewhere in
>> Trust Zone.
>
> Linux does not write into cmd-db region. This region is write
> protected by XPU. Making this region uncached magically solves the XPU
> write fault
> issue.
>
> Can you please include above details?

Sure, I'll add this to the next version.

>> The only reason it is working right now is because Qualcomm
>> Hypervisor
>> maps the same region as Non-Cacheable memory in Stage 2 translation
>> tables. The issue manifests if we want to use another hypervisor (like
>> Xen or KVM), which does not know anything about those specific
>> mappings. This patch fixes the issue by mapping the shared memory as
>> Write-Through. This removes dependency on correct mappings in Stage 2
>> tables.
>
> Using MEMREMAP_WC also resolves for qcm6490, see below comment.
>
>> I tested this on SA8155P with Xen.
>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>> ---
>>   drivers/soc/qcom/cmd-db.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
>> index a5fd68411bed5..dd5ababdb476c 100644
>> --- a/drivers/soc/qcom/cmd-db.c
>> +++ b/drivers/soc/qcom/cmd-db.c
>> @@ -324,7 +324,7 @@ static int cmd_db_dev_probe(struct platform_device *=
pdev)
>>   		return -EINVAL;
>>   	}
>>   -	cmd_db_header =3D memremap(rmem->base, rmem->size, MEMREMAP_WB);
>> +	cmd_db_header =3D memremap(rmem->base, rmem->size, MEMREMAP_WT);
>
> In downstream, we have below which resolved similar issue on qcm6490.
>
> cmd_db_header =3D memremap(rmem->base, rmem->size, MEMREMAP_WC);
>
> Downstream SA8155P also have MEMREMAP_WC. Can you please give it a try
> on your device?

Yes, MEMREMAP_WC works as well. This opens the question: which type is
more correct? I have no deep understanding in QCOM internals so it is
hard to me to answer this question.

--=20
WBR, Volodymyr=