From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: ami.com, ip: 63.147.10.40, mailfrom: felixp@ami.com) Received: from atlmailgw1.ami.com (atlmailgw1.ami.com [63.147.10.40]) by groups.io with SMTP; Fri, 24 May 2019 05:52:56 -0700 X-AuditID: ac1060b2-0c51d9c0000059e1-14-5ce7e925e989 Received: from atlms2.us.megatrends.com (atlms2.us.megatrends.com [172.16.96.152]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by atlmailgw1.ami.com (Symantec Messaging Gateway) with SMTP id 52.50.23009.529E7EC5; Fri, 24 May 2019 08:52:53 -0400 (EDT) Received: from ATLMS1.us.megatrends.com ([fe80::8c55:daf0:ef05:5605]) by atlms2.us.megatrends.com ([fe80::29dc:a91e:ea0c:cdeb%12]) with mapi id 14.03.0415.000; Fri, 24 May 2019 08:52:53 -0400 From: "Felix Polyudov" To: "devel@edk2.groups.io" , "'zhichao.gao@intel.com'" CC: Jian J Wang , Hao A Wu , Ray Ni , Star Zeng , Liming gao , Sean Brogan , "Michael Turner" , Bret Barkelew , Michael D Kinney , Eric Dong , Laszlo Ersek , "Andrew Fish (afish@apple.com)" Subject: Re: [edk2-devel] [PATCH 0/6] Fix race condition and add event protocol Thread-Topic: [edk2-devel] [PATCH 0/6] Fix race condition and add event protocol Thread-Index: AQHVEe43QbLHUetFFkiWCaq3vvfnYqZ6Lflg Date: Fri, 24 May 2019 12:52:53 +0000 Message-ID: <9333E191E0D52B4999CE63A99BA663A00302C8EE0A@atlms1.us.megatrends.com> References: <20190524050437.38616-1-zhichao.gao@intel.com> In-Reply-To: <20190524050437.38616-1-zhichao.gao@intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.99.93] content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIKsWRmVeSWpSXmKPExsWyRiBhhq7qy+cxBpfOmlpMv/2YxeLdloVs Fu0TZrNZbH4RbHH11i8mi3nfZrBaLDu2g8Vixb0N7BYdHf+YLFbtesJq8WX1e0aLhY82M1vs 67W2+LdtBrMDn8fWkz/YPLZ/v8DosXjPSyaP1h1/2T3e77vKFsAa1cBok5iXl1+SWJKqkJJa nGyrFFCUWZaYXKmkkJliq2SopFCQk5icmpuaV2KrlFhQkJqXomTHpYABbIDKMvMUUvOS81My 89JtlTyD/XUtLEwtdQ2V7EIyUhUy89Lyi3ITSzLz8xSS8/NKgKpTU4CiCgldnBlrPm1jKZip VnH14hm2Bsbvcl2MnBwSAiYSE789Zexi5OIQEtjFJPHlYwcTSEJI4DCjxMabLCA2m4CqxPHV zWC2iECaxPNfK5lBGpgF7jJL/JncwN7FyMEhLBAoceKVCURNkMSTjQ+ZIWwjiR+/G8BmsgDN mfxjHdgcXqDy1RevMkPsspKYt6MBzOYUsJaYsOwrG4jNKCAm8f3UGrBeZgFxiVtP5jNBHC0g sWTPeWYIW1Ti5eN/rBC2gsSW953sEPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYRWchGTsL ScssJC2zkLQsYGRZxSiUWJKTm5iZk15uqJeYm6mXnJ+7iRGSojbtYGy5aH6IUYCDUYmHd+um 5zFCrIllxZW5hxglOJiVRHhj9z+LEeJNSaysSi3Kjy8qzUktPsToBAyWicxS3KDoAsZ/vLGB gZQojGNoYmZibmRuaGlibmysJM47I+RyjJBAOjAdZaemFqQWwQxh4uCUamD0efXq24p9B98G CbIvO/4+v59vXrAzC/OMzjCdR49k1/w3Zjpk+OHTHvbnrxneXN806/A+Xi0NJ3URicY217wX Sl2xB1ns81JTTWIWHXmg6nuhRS/tl/DuDZUJe584bZ9vxMee/3h5631J1lul5qXrXhSd36zl PeW+vp6e+241T759v5hlg/4osRRnJBpqMRcVJwIA9NWnfnQDAAA= Content-Language: en-US Content-Type: text/plain; charset="us-ascii" I think there is a bigger problem with the idle event signaling by CoreWaitF= orEvent. On every iteration CoreWaitForEvent checks user events, and, if none is sign= aled, the function signals special idle event. This itself is not a problem. However, on many (most?) platforms CPU driver= installs idle event handler that calls CpuSleep (f.i. refer to IdleLoopEventCallback in UefiCpuPkg/CpuDxe/CpuDxe.c and ArmPk= g/Drivers/CpuDxe/CpuDxe.c). CpuSleep "places the CPU in a sleep state until an interrupt is received", w= hich changes the nature of the WaitForEvent function arguably violating the= UEFI specification. According to the UEFI specification: "The list of events in the Event array are evaluated in order from first to= last, and this evaluation is repeated until an event is signaled or an erro= r is detected." The sentence above implies continues evaluation (polling model). An idle event callback that sends CPU to a sleep state, converts WaitForEven= t from a continues polling function into a poll-once-per-timer-period function (tim= er is typically the only enabled HW interrupt), which reduces quality of service provided by WaitForEvent and can lead to mi= ssed events. For example, UEFI application that reads key strokes using gBS->WaitForEvent= (..)/ConIn->ReadKey(...) sequence will be losing key strokes if they are coming faster than 18.2 keys per seco= nd on a system based on legacy timer. So, should idle event support be removed from CoreWaitForEvent? -----Original Message----- From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Gao, Z= hichao Sent: Friday, May 24, 2019 1:05 AM To: devel@edk2.groups.io Cc: Jian J Wang; Hao A Wu; Ray Ni; Star Zeng; Liming gao; Sean Brogan; Micha= el Turner; Bret Barkelew; Michael D Kinney; Eric Dong; Laszlo Ersek Subject: [edk2-devel] [PATCH 0/6] Fix race condition and add event protocol There is a race condition in CoreWaitForEvent function: If an interrupt happens between CheckEvent and gIdleLoopEvent, there would be a event pending during cpu sleep. So it is required to check the gEventPending with the interrupt disabled. Implement a gEfiCpu2ProtocolGuid to fix that. The protocol include one interface to enable interrupt and put the cpu to sleep. Add a event protocol gEdkiiCommonEventProtocolGuid to support all TPL event. It is require for PI drivers that use HW interrput. Cc: Jian J Wang Cc: Hao A Wu cc: Ray Ni Cc: Star Zeng Cc: Liming gao Cc: Sean Brogan Cc: Michael Turner Cc: Bret Barkelew Cc: Michael D Kinney Cc: Eric Dong Cc: Laszlo Ersek Sean Brogan (5): MdeModulePkg: Add gEdkiiCommonEventProtocolGuid for event MdePkg/BaseLib.h: Add EnableInterruptsAndSleep function declare MdePkg/BaseLib: Implement EnableInterruptsAndSleep MdePkg: Add gEfiCpu2ProtocolGuid and header file MdeModulePkg/DxeMain: Implement common event protocol Zhichao Gao (1): UefiCpuPkg/CpuDxe: Implement Cpu2 protocol MdeModulePkg/Core/Dxe/DxeMain.h | 64 ++++++++++- MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 22 ++++ .../Core/Dxe/DxeMain/DxeProtocolNotify.c | 1 + MdeModulePkg/Core/Dxe/Event/Event.c | 102 ++++++++++++++++-- MdeModulePkg/Core/Dxe/Event/Event.h | 2 +- MdeModulePkg/Include/Protocol/CommonEvent.h | 18 ++++ MdeModulePkg/MdeModulePkg.dec | 3 + MdePkg/Include/Library/BaseLib.h | 11 ++ MdePkg/Include/Protocol/Cpu2.h | 43 ++++++++ .../Library/BaseLib/Ia32/EnableInterrupts.c | 18 +++- .../BaseLib/Ia32/EnableInterrupts.nasm | 15 ++- .../Library/BaseLib/X64/EnableInterrupts.nasm | 15 ++- MdePkg/MdePkg.dec | 3 + UefiCpuPkg/CpuDxe/CpuDxe.c | 40 ++++++- UefiCpuPkg/CpuDxe/CpuDxe.h | 15 +++ UefiCpuPkg/CpuDxe/CpuDxe.inf | 3 +- 17 files changed, 358 insertions(+), 18 deletions(-) create mode 100644 MdeModulePkg/Include/Protocol/CommonEvent.h create mode 100644 MdePkg/Include/Protocol/Cpu2.h -- 2.21.0.windows.1 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41302): https://edk2.groups.io/g/devel/message/41302 Mute This Topic: https://groups.io/mt/31741727/1498468 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [felixp@ami.com] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Please consider the environment before printing this email. The information contained in this message may be confidential and proprietar= y to American Megatrends, Inc. This communication is intended to be read on= ly by the individual or entity to whom it is addressed or by their designee.= If the reader of this message is not the intended recipient, you are on not= ice that any distribution of this message, in any form, is strictly prohibit= ed. Please promptly notify the sender by reply e-mail or by telephone at 77= 0-246-8600, and then delete or destroy all copies of the transmission.