Re: [PATCH] OvmfPkg/PlatformDebugLibIoPort: fix port detection for use in the DXE Core

[Laszlo Ersek <lersek@redhat.com>]

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.biesheuvel@linaro.org>
>> Cc: Brijesh Singh <brijesh.singh@amd.com>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Fixes: c09d9571300a089c35f5df2773b70edc25050d0d
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Laszlo Ersek <lersek@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.justen@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
>>