From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) by mx.groups.io with SMTP id smtpd.web12.22676.1594655830116671634 for ; Mon, 13 Jul 2020 08:57:10 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=vBOLEZM4; spf=pass (domain: apple.com, ip: 17.151.62.66, mailfrom: afish@apple.com) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.43/8.16.0.42) with SMTP id 06DFtdBj031770; Mon, 13 Jul 2020 08:57:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=43jOzj3e+OIxOB5mU99ppUHZ78TCgJg9tKWuZTke0ps=; b=vBOLEZM4tgtSLf1kdcD+H3Nv+Ydl/eOgjWpweOX1JAO1htP2XCOtXsHX/O31/z8zhida rJEvegPpiIqTMBtksMUle+Md30g5p/eDvAVPr4n24M/wGaNRYEHeJzgbzi/HxTl2NQzi 3raSwrm9+roxg2eMuzuRMJ2Cs/KXDz/IkV2ONrbKUMfsFRlbjW8FFCS3QcuqY72Rgy0w vjbSQeEGbkeXzAIVEKtiZs75GZa0EcGt1KdB88H8yLpC2AkDoxXG+yywKJf4qe46nzZi tjga1c99zkgxHt7T0lfbqD2eB3+pt8xH5pKuO/UgQIYs76Wn9w6K2kNzhGtgA654ft0e OA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp01.apple.com with ESMTP id 327wdhtavc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 13 Jul 2020 08:57:08 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QDF00S6Q0B8BZJ0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 13 Jul 2020 08:57:08 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QDE00R00ZXHWS00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 13 Jul 2020 08:57:08 -0700 (PDT) X-Va-A: X-Va-T-CD: e0acb9dc03d22e4581b62f3d752335f3 X-Va-E-CD: 01093fc030ab03d36fd5e7ee208a4cd6 X-Va-R-CD: a3f879d2c1accc6e75c86140cc99a4ed X-Va-CD: 0 X-Va-ID: 65555557-048b-4ff7-bb31-29cc52cbc485 X-V-A: X-V-T-CD: e0acb9dc03d22e4581b62f3d752335f3 X-V-E-CD: 01093fc030ab03d36fd5e7ee208a4cd6 X-V-R-CD: a3f879d2c1accc6e75c86140cc99a4ed X-V-CD: 0 X-V-ID: e6085217-4c45-4cfb-a648-9ac3e32fa1d0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-07-13_15:2020-07-13,2020-07-13 signatures=0 Received: from [17.235.56.38] (unknown [17.235.56.38]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QDF00RBP0B0X100@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 13 Jul 2020 08:57:02 -0700 (PDT) From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [edk2-devel] [edk2-discuss] Need memory barriers in IoLib for AARCH64 Date: Mon, 13 Jul 2020 08:57:00 -0700 In-reply-to: <0d68b7da-01c9-f696-7eb4-ebbef8a5cf0f@redhat.com> Cc: wasim.khan@nxp.com, Mike Kinney , "liming.gao@intel.com" , "Leif Lindholm (Nuvia address)" To: edk2-devel-groups-io , Laszlo Ersek References: <0d68b7da-01c9-f696-7eb4-ebbef8a5cf0f@redhat.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-07-13_15:2020-07-13,2020-07-13 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_91B4FF20-7C4A-4C1B-92EF-AC08345AE039" --Apple-Mail=_91B4FF20-7C4A-4C1B-92EF-AC08345AE039 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Wasim, Was there a specific function you had concerns about? Or was it confusion = about the names? Hopefully the name confusion would have been fixed by 089e= 9c19a8c? Thanks, Andrew Fish > On Jul 13, 2020, at 8:31 AM, Laszlo Ersek wrote: >=20 > On 07/12/20 18:54, Andrew Fish via groups.io wrote: >>=20 >>=20 >>> On Jul 11, 2020, at 10:17 PM, Wasim Khan > wrote: >>>=20 >>> Hello=20 >>>=20 >>> Any comments ? >>>=20 >>=20 >> I don=E2=80=99t see IoLibArm.c in master? I see IoLibNoIo.c.=20 >=20 > That's due to the rename in commit 089e9c19a8c1 > ("MdePkg/BaseIoLibIntrinsic: Rename IoLibArm.c=3D>IoLibNoIo.c", > 2020-05-07), which has been first included in edk2-stable202005. >=20 > I think Ard is away at the moment, so I'm adding Leif to the CC list. >=20 > Thanks > Laszlo >=20 >> The MMIO function look like ARM assembler with the correct barrier inst= ructions. The IO operations in this lib are the x86 in/out instructions, so= they just ASSERT on ARM.=20 >>=20 >> On the X86 MemoryFence() is just a serializing intrinsic for the compil= er to prevent optimizations from breaking the code, kind of like how you ne= ed to make MMIO as volatile in C.=20 >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>>> -----Original Message----- >>>> From: Wasim Khan >>>> Sent: Friday, July 10, 2020 6:20 PM >>>> To: michael.d.kinney@intel.com; liming.gao@intel.com; devel@edk2.grou= ps.io >>>> Subject: [edk2-discuss] Need memory barriers in IoLib for AARCH64 >>>>=20 >>>> Hello, >>>>=20 >>>> MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf: >>>> IoLib library uses IoLibArm.c for AARCH64/ARM architecture and IoLib.= c for >>>> other architectures. >>>>=20 >>>> While IoLib.c already has memory barriers in MmioWrite functions, the= re >>>> barriers are missing in IoLibArm.c Is there any reason for **not** ad= ding these >>>> memory barriers in IoLibArm.c to guarantee that all MMIO operations a= re >>>> serialized ? >>>>=20 >>>> I am facing some issues and I need to add memory barriers in IoLibArm= .c for >>>> AARCH64 also . >>>>=20 >>>>=20 >>>> Regards, >>>> Wasim >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_91B4FF20-7C4A-4C1B-92EF-AC08345AE039 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Wasim,
Was there a specific function you had con= cerns about? Or was it confusion about the names? Hopefully the name confus= ion would have been fixed by 089e9c19a8c?

Thanks,
Andrew Fish

On Jul 13, 2020= , at 8:31 AM, Laszlo Ersek <lersek@redhat.com> wrote:

On 07/12/20 18:54, Andrew Fish via groups.io wrote:


=
On Jul 11, 2020, at 10:17 PM, Wasim Kh= an <wasim.khan@nxp.com<= /a>> wrote:

Hello 

Any comments ?


I don=E2=80=99t see IoL= ibArm.c in master? I see IoLibNoIo.c.=  

That's due to the rename in commit 089e9c19a8c1
("MdePkg/BaseIoLibIntrinsic: Rename = IoLibArm.c=3D>IoLibNoIo.c",
2020-05-07), which has been first included in edk2-stable202005.

I think Ard is away at the moment, so I'm adding Leif to the = CC list.

Thanks
Laszlo

The MMIO function look like AR= M assembler with the correct barrier instructions. The IO operations in thi= s lib are the x86 in/out instructions, so they just ASSERT on ARM. 

On = the X86 MemoryFence() is just a serializing intrinsic for the compiler to p= revent optimizations from breaking the code, kind of like how you need to m= ake MMIO as volatile in C. 

Thanks,

Andrew= Fish

-----Original Message-----
= From: Wasim Khan
Sent: Friday, July 10, 2020 6:20 PM
To: michael= .d.kinney@intel.com; liming.gao@intel.com; devel@edk2.groups.io
Subject: [edk2-discuss] Need memo= ry barriers in IoLib for AARCH64

Hello,

MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic= .inf:
IoLib library uses IoLibArm.c for AARCH64/ARM architect= ure and IoLib.c for
other architectures.

While IoLib.c already has memory barriers in MmioWrite functions, = there
barriers are missing in IoLibArm.c Is there any reason = for **not** adding these
memory barriers in IoLibArm.c to gua= rantee that all MMIO operations are
serialized ?

I am facing some issues and I need to add memory barriers = in IoLibArm.c for
AARCH64 also .


Regards,
Wasim










--Apple-Mail=_91B4FF20-7C4A-4C1B-92EF-AC08345AE039--