From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4294081F1C for ; Thu, 1 Dec 2016 09:56:03 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A1CF08FCE8; Thu, 1 Dec 2016 17:56:02 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-138.phx2.redhat.com [10.3.116.138]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB1Hu0Ak017729; Thu, 1 Dec 2016 12:56:00 -0500 From: Laszlo Ersek To: edk2-devel-01 Cc: David Wei , Feng Tian , Liming Gao , Mang Guo , Michael D Kinney , Star Zeng Date: Thu, 1 Dec 2016 18:55:53 +0100 Message-Id: <20161201175556.2479-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 01 Dec 2016 17:56:02 +0000 (UTC) Subject: [PATCH 0/3] MdePkg, MdeModulePkg, Vlv2TbltDevicePkg: 64-bit LoopTimes in S3 MEM_POLL X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 17:56:03 -0000 While working on S3 boot script related stuff in OVMF, I wanted to see if infinite blocking was possible in the various POLL opcodes. While edk2's implementation of IO_POLL, PCI_CONFIG_POLL and PCI_CONFIG2_POLL follows the PI spec vol5 closely, even internally (using 100ns delay units), the MEM_POLL internals differ -- they are microseconds based. That's not a problem per se (it's just a different internal opcode representation, which is fine); the problem is that the current internals don't conform to the spec: in 32-bit builds, the UINT64 number of 100ns units that the caller intends to wait for is silently truncated, for no good reason. This issue is not hard to fix (we can even keep the microseconds-based internals), so let's fix it. Repo: https://github.com/lersek/edk2/ Branch: mempoll_looptimes_64bit Cc: David Wei Cc: Feng Tian Cc: Liming Gao Cc: Mang Guo Cc: Michael D Kinney Cc: Star Zeng Thanks Laszlo Laszlo Ersek (3): MdePkg, MdeModulePkg: S3BootScriptSaveMemPoll(): accept 64-bit LoopTimes MdeModulePkg: S3SaveStateDxe, SmmS3SaveState: save 64-bit LoopTimes Vlv2TbltDevicePkg/BootScriptSaveDxe: save 64-bit LoopTimes MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c | 2 +- MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c | 8 ++++---- MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 8 ++++---- MdePkg/Include/Library/S3BootScriptLib.h | 2 +- MdePkg/Library/BaseS3BootScriptLibNull/BootScriptLib.c | 2 +- Vlv2TbltDevicePkg/BootScriptSaveDxe/ScriptSave.c | 4 ++-- 6 files changed, 13 insertions(+), 13 deletions(-) -- 2.9.2