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 <ard.biesheu...@linaro.org>
>> Cc: Brijesh Singh <brijesh.si...@amd.com>
>> Cc: Jordan Justen <jordan.l.jus...@intel.com>
>> Fixes: c09d9571300a089c35f5df2773b70edc25050d0d
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
>> ---
>>
>> 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 <Base.h>
>> #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 <jordan.l.jus...@intel.com>
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
>>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
