From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by mx.groups.io with SMTP id smtpd.web12.2837.1662488274126415523 for ; Tue, 06 Sep 2022 11:17:54 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=BlFMp2rB; spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: quicinc.com, ip: 205.220.168.131, mailfrom: quic_rcran@quicinc.com) Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 286CUZSi013992; Tue, 6 Sep 2022 18:17:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=bxiyLdBkzNMREQVrnAXlXSkeZ92NfBoL8UJ0nmQNkfo=; b=BlFMp2rBzpc3HXAJu4t/WvXEetU4udEircpbAZlNQIQL0hoAdq2U9nTPVic/+pSRrt2r 7HE09rsEkst57w/EzhLWlWWJebTUrRY67NTdvR0XWbBqaocizRC5CM5U6JZQlfExRNgb a6Uw6KU3axa3814seZgNYl1fjPuIb3pqo/zU9kUayBZplyBi85dSv84g81bM2m4mxhzD 3bF5oNr1P4AVMJ/fDeRasP30yt2OSMuC9A2RiroiZKJ3Y8xqpF+Xeiw90qhq+ne9oMaM hOZZ5VqgsLgG0AX/vJycP9tGIB8EndhfeCewDqSRwVjqpkWqiPDu51fkTJgQf6aORjY7 VQ== Received: from nasanppmta04.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3jdvdyb71g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Sep 2022 18:17:43 +0000 Received: from nasanex01b.na.qualcomm.com (nasanex01b.na.qualcomm.com [10.46.141.250]) by NASANPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 286IHgcH027063 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 6 Sep 2022 18:17:42 GMT Received: from [10.110.125.70] (10.80.80.8) by nasanex01b.na.qualcomm.com (10.46.141.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Tue, 6 Sep 2022 11:17:41 -0700 Message-ID: <94c12ff5-6329-6b67-6818-6b9da1e69cd5@quicinc.com> Date: Tue, 6 Sep 2022 12:17:41 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [edk2-devel] [PATCH 0/2] Add support EFI_MP_SERVICES_PROTOCOL on AARCH64 To: Ard Biesheuvel , , CC: Leif Lindholm , Ard Biesheuvel , Sami Mujawar , Jian J Wang , Liming Gao References: <20220829155955.3767-1-rebecca@quicinc.com> <1b826591-5abc-ef17-c47a-22918318eb20@quicinc.com> From: "Rebecca Cran" In-Reply-To: X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01b.na.qualcomm.com (10.46.141.250) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: R5Ht1E1Mk4_kI0qYtI-Rt7Nechcy75xS X-Proofpoint-ORIG-GUID: R5Ht1E1Mk4_kI0qYtI-Rt7Nechcy75xS X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-06_09,2022-09-06_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxlogscore=937 mlxscore=0 suspectscore=0 bulkscore=0 impostorscore=0 priorityscore=1501 lowpriorityscore=0 adultscore=0 clxscore=1015 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2209060085 Content-Language: en-US Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 9/6/22 11:53, Ard Biesheuvel wrote: > On Tue, 6 Sept 2022 at 19:01, Rebecca Cran wrote: >> My only concern is about the call in MpServicesTest: >> >> WriteBackDataCacheRange ((VOID *)&ApFunction, 32); >> >> Obviously the '32' is a magic number and should be something based on the size of ApFunction. >> But I don't think there's a portable way to calculate what that value should be. >> > Why exactly do we need that call? > > I understand that some of the code needs to be clean to the PoC (on > ARM) so that the AP can fetch instructions with the MMU and caches > disabled. But the actual routine passed into the API is called with > the MMU and caches on, right? It's a leftover from the work you did on the code, before I changed it to have the MMU and caches enabled on the APs. I'll go through and remove it and any others for the v2 patch which I'll send out later today (which will also fix the Usage text for MpServicesTest). -- Rebecca Cran