From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (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 AA651210C2D94 for ; Fri, 3 Aug 2018 08:08:15 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D290B406F8A3; Fri, 3 Aug 2018 15:08:14 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-198.rdu2.redhat.com [10.10.120.198]) by smtp.corp.redhat.com (Postfix) with ESMTP id E7259213ED6A; Fri, 3 Aug 2018 15:08:13 +0000 (UTC) To: Jordan Justen , edk2-devel-01 Cc: Ard Biesheuvel , Brijesh Singh References: <20180803003045.31740-1-lersek@redhat.com> <153327854869.17436.13213153845980323214@jljusten-skl> From: Laszlo Ersek Message-ID: Date: Fri, 3 Aug 2018 17:08:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <153327854869.17436.13213153845980323214@jljusten-skl> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 03 Aug 2018 15:08:14 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 03 Aug 2018 15:08:14 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH] OvmfPkg/PlatformDebugLibIoPort: fix port detection for use in the DXE Core X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 15:08:15 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/03/18 08:42, Jordan Justen wrote: > On 2018-08-02 17:30:45, Laszlo Ersek wrote: >> The DXE Core is one of those modules that call >> ProcessLibraryConstructorList() manually. >> >> Before DxeMain() [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c] calls >> ProcessLibraryConstructorList(), and through it, our >> PlatformDebugLibIoPortConstructor() function, DxeMain() invokes the >> DEBUG() macro multiple times. That macro lands in our >> PlatformDebugLibIoPortFound() function -- which currently relies on the >> "mDebugIoPortFound" global variable that has (not yet) been set by the >> constructor. As a result, early debug messages from the DXE Core are lost. >> >> Move the device detection into PlatformDebugLibIoPortFound(), also caching >> the fact (not just the result) of the device detection. >> >> (We could introduce a separate DebugLib instance just for the DXE Core, >> but the above approach works for all modules that currently consume the >> PlatformDebugLibIoPort instance (which means "everything but SEC").) >> >> This restores messages such as: >> >>> CoreInitializeMemoryServices: >>> BaseAddress - 0x7AF21000 Length - 0x3CDE000 MinimalMemorySizeNeeded - 0x10F4000 >> >> Keep the empty constructor function -- OVMF's DebugLib instances have >> always had constructors; we had better not upset constructor dependency >> ordering by making our instance(s) constructor-less. >> >> Cc: Ard Biesheuvel >> Cc: Brijesh Singh >> Cc: Jordan Justen >> Fixes: c09d9571300a089c35f5df2773b70edc25050d0d >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Laszlo Ersek >> --- >> >> Notes: >> Brijesh, can you please test this patch on SEV, with and without >> capturing the debug port? (In the first case, the debug log should just >> work; in the second case, the boot should remain fast.) Thanks! >> >> Repo: https://github.com/lersek/edk2.git >> Branch: debuglib_dxecore >> >> OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c | 24 ++++++++++++++++---- >> 1 file changed, 20 insertions(+), 4 deletions(-) >> >> diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c >> index 81c44eece95f..74aef2e37b42 100644 >> --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c >> +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c >> @@ -16,14 +16,26 @@ >> #include >> #include "DebugLibDetect.h" >> >> + >> +// >> +// Set to TRUE if the debug I/O port has been checked >> +// >> +STATIC BOOLEAN mDebugIoPortChecked = FALSE; > > Could this be a static variable in the function? Yes, both variables could be defined in PlatformDebugLibIoPortFound() now -- and that would actually be superior coding practice in any other C-language project :) In edk2, objects with block scope declaration, static storage duration, and no linkage (aka "function global variables") basically don't exist. I've sneakily added a handful of them to OvmfPkg, over time, but only so I could attach names to string literals that I'd use multiple times. See "Fallback" in "Library/PlatformBootManagerLib/BdsPlatform.c", and "ConvFallBack" in "Library/QemuBootOrderLib/QemuBootOrderLib.c". (Such variables don't get the "m" prefix though.) > If not, should it be follow by a blank line? In edk2 there is "prior art" for both keeping and not keeping [*] a blank line just before a comment block. I strive to decide consciously, and this was no exception -- I felt that the 1st and 3rd lines in the subsequent comment // // Set to TRUE if the debug I/O port is enabled // gave enough separation. [*] One example of the many: see near the macro and enum constant definitions in "MdePkg/Include/Uefi/UefiMultiPhase.h". > > I agree that Brijesh should verify it, but pending that: > > Reviewed-by: Jordan Justen Thanks! Should I resubmit the patch for function-scoping (and renaming) the global variables, or for inserting the blank linke? (I guess I could insert the blank line right before I push, too, if you prefer that.) Thanks! Laszlo >> // >> // Set to TRUE if the debug I/O port is enabled >> // >> STATIC BOOLEAN mDebugIoPortFound = FALSE; >> >> /** >> - This constructor function checks if the debug I/O port device is present, >> - caching the result for later use. >> + This constructor function must not do anything. >> + >> + Some modules consuming this library instance, such as the DXE Core, invoke >> + the DEBUG() macro before they explicitly call >> + ProcessLibraryConstructorList(). Therefore the auto-generated call from >> + ProcessLibraryConstructorList() to this constructor function may be preceded >> + by some calls to PlatformDebugLibIoPortFound() below. Hence >> + PlatformDebugLibIoPortFound() must not rely on anything this constructor >> + could set up. >> >> @retval RETURN_SUCCESS The constructor always returns RETURN_SUCCESS. >> >> @@ -34,12 +46,12 @@ PlatformDebugLibIoPortConstructor ( >> VOID >> ) >> { >> - mDebugIoPortFound = PlatformDebugLibIoPortDetect(); >> return RETURN_SUCCESS; >> } >> >> /** >> - Return the cached result of detecting the debug I/O port device. >> + At the first call, check if the debug I/O port device is present, and cache >> + the result for later use. At subsequent calls, return the cached result. >> >> @retval TRUE if the debug I/O port device was detected. >> @retval FALSE otherwise >> @@ -51,5 +63,9 @@ PlatformDebugLibIoPortFound ( >> VOID >> ) >> { >> + if (!mDebugIoPortChecked) { >> + mDebugIoPortFound = PlatformDebugLibIoPortDetect (); >> + mDebugIoPortChecked = TRUE; >> + } >> return mDebugIoPortFound; >> } >> -- >> 2.14.1.3.gb7cf6e02401b >>