From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=jGEURZ84; spf=pass (domain: apple.com, ip: 17.151.62.67, mailfrom: afish@apple.com) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) by groups.io with SMTP; Wed, 31 Jul 2019 11:08:07 -0700 Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6VI7M8w043144; Wed, 31 Jul 2019 11:08:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=m1qIVlDxBU9RVmt5VEAuC5TD9ABLnK6iNOByi6xXCdE=; b=jGEURZ848CzJ/1MEX6X/TAQxEP7Ao4EGNyCkfhhdY9zfTd6ztbaHeHlCFASdP+SmI8qL dYeQsQ0GQlWGFGH3kxJ71JGaPFITBVLjZynl840p1CUiQob2O3tsJ7RO/jh1dxWPSJMA vaiKlKQf0Wwg6eU+G65A5q0d0sOl6KppE56FNPOWs1KjonaytvbGgQFhfPC8rod8QXj+ xdxufeD96LXHqgTPPUvdtdoXnFAWtQSpAA8JbssNChZnrN0lHeESBZCSuVL/46MHkFXK RM6TWUUAijQdI7SRrDxK0/X0RopvIVpSRD6KdLqDObSO46my7nnSSA7YiAidcwVxk+ml vQ== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2u2p717m0c-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 Jul 2019 11:08:05 -0700 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PVI00BW1QDDEV90@ma1-mtap-s02.corp.apple.com>; Wed, 31 Jul 2019 11:08:04 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PVI00C00QC8RU00@nwk-mmpp-sz12.apple.com>; Wed, 31 Jul 2019 11:08:03 -0700 (PDT) X-Va-A: X-Va-T-CD: 9a944300b48f07f06aa7e0165fb7dbb6 X-Va-E-CD: 9e7cb8c6aa8d6eddfb837a735a3f2f20 X-Va-R-CD: 94a6eae90dc3c7c516495aa7ca0df601 X-Va-CD: 0 X-Va-ID: a32c7c42-b9b8-41a0-94e7-e73390025da0 X-V-A: X-V-T-CD: 9a944300b48f07f06aa7e0165fb7dbb6 X-V-E-CD: 9e7cb8c6aa8d6eddfb837a735a3f2f20 X-V-R-CD: 94a6eae90dc3c7c516495aa7ca0df601 X-V-CD: 0 X-V-ID: 7f99dda7-2374-412e-aced-42056213afb6 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-31_09:,, signatures=0 Received: from da0602a-dhcp178.apple.com (da0602a-dhcp178.apple.com [17.226.23.178]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PVI00CX2QASOL10@nwk-mmpp-sz12.apple.com>; Wed, 31 Jul 2019 11:06:28 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: <0ED49D9C-9F20-460C-A9E9-0B94CC5A88A7@apple.com> MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [edk2-devel] [Patch 0/2] UefiCpuPkg: Default avoid print. Date: Wed, 31 Jul 2019 11:06:17 -0700 In-reply-to: <3a28f2c6-6ef1-c830-b3c6-3cf69c5ca60f@hpe.com> Cc: Laszlo Ersek , Eric Dong , Ray Ni , Mike Kinney To: devel@edk2.groups.io, brian.johnson@hpe.com References: <20190731073502.24640-1-eric.dong@intel.com> <3a28f2c6-6ef1-c830-b3c6-3cf69c5ca60f@hpe.com> X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-31_09:,, signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_F753301B-064E-4669-9468-14885F786039" --Apple-Mail=_F753301B-064E-4669-9468-14885F786039 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 31, 2019, at 9:34 AM, Brian J. Johnson wr= ote: >=20 > On 7/31/19 7:43 AM, Laszlo Ersek wrote: >> (adding Mike) >> On 07/31/19 09:35, Eric Dong wrote: >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1984 >>>=20 >>> Current debug message brings much restriction for the platform >>> which use this driver. >>>=20 >>> For PEI and DXE phase, platform mush link base DebugLib (without >>> using any pei/dxe services, even for its dependent libraries). >>>=20 >>> This patch default disable this debug message, only open it when >>> need to debug the related code. >>>=20 >>> Signed-off-by: Eric Dong >>> Cc: Ray Ni >>> Cc: Laszlo Ersek >>>=20 >>> Eric Dong (2): >>> UefiCpuPkg/RegisterCpuFeaturesLib: Default avoid print. >>> UefiCpuPkg/PiSmmCpuDxeSmm: Default avoid print. >>>=20 >>> .../Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 4 +++= - >>> UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 4 +++= - >>> 2 files changed, 6 insertions(+), 2 deletions(-) >>>=20 >> The basic problem seems to be that APs should not use "thick" services >> that might underlie the DebugLib instance that is picked by the >> platform. That requirement appears sane to me. >> I think I disagree with the proposed mitigation though. Reasons: >> (a) The mitigation is duplicated to independent modules. >> (b) It is not possible to change the debug mask without modifying C >> language source code. >> (c) Passing a zero log mask to DEBUG() on the APs does not guarantee >> thread safety: >> - The DEBUG() macro calls DebugPrintEnabled() regardless of the log mas= k >> passed to DEBUG(). >> - The DEBUG() macro may or may not call DebugPrintLevelEnabled(), >> dependent on architecture & toolchain. >> - Both DebugPrintEnabled() and DebugPrintLevelEnabled() are DebugLib >> interfaces. The library instance may implement them unsafely for APs, >> and a zero log mask at the DEBUG call site could not prevent that. >> - Finally, DebugPrint() itself could invoke thread-unsafe logic, before >> consulting the log mask. >> I would propose the following, instead: >> (i) Introduce BIT6 for PcdDebugPropertyMask in "MdePkg.dec". The defaul= t >> value should be zero. The bit stands for "DEBUG is safe to call on APs"= . >> (ii) Add a macro called AP_DEBUG to . >> This macro should work the same as DEBUG, except it should do nothing i= f >> BIT6 in PcdDebugProperyMask is clear. >> Fetching PcdDebugPropertyMask inside AP_DEBUG() is safe, because: >> - the PCD can only be fixed-at-build or patchable-in-module (therefore >> it is safe to read on APs -- no PCD PPI or PCD Protocol is needed); >> - PcdDebugPropertyMask is a preexistent PCD that *all* existent DebugLi= b >> instances are expected to consume -- per the API specifications in >> --, therefore no new PCD dependency would be introduced to >> DebugLib instances. >> (iii) Modules that call DEBUG on APs should replace those calls with >> AP_DEBUG. Code that currently calls DEBUG while running on either BSP o= r >> APs should discriminate those cases from each other, and use AP_DEBUG >> explicitly, when it runs on APs. >> As a further refinement, a macro called MP_DEBUG could be introduced >> too, with a new initial parameter called "Bsp". If the Bsp parameter is >> TRUE, then MP_DEBUG is identical to DEBUG. Otherwise, MP_DEBUG is >> identical to AP_DEBUG. This way, DEBUG() calls such as described above >> wouldn't have to be split into DEBUG / AP_DEBUG calls; they could be >> changed into MP_DEBUG calls (with an extra parameter in the front). >> (iv) platforms can set BIT6 in PcdDebugPropertyMask in DSC files. This >> need not be a full platform-level setting: the PCD can be overridden in >> module scope, just like the DebugLib resolution can be module-scoped. >> As an end result, AP_DEBUG messages will disappear by default (safely), >> and platforms will have to do extra work only if they want AP_DEBUG >> messages to appear. Otherwise the change is transparent to platforms. >> And, I think that AP_DEBUG belongs in MdePkg (and not UefiCpuPkg) >> because both DebugLib and EFI_MP_SERVICES_PROTOCOL are declared in >> MdePkg. While UefiCpuPkg provides the multiprocessing implementation fo= r >> IA32 and X64, the problem is architecture-independent. Furthermore, the >> problem is a long-standing and recurrent one -- please refer to commit >> 81f560498bf1, for example --, so it makes sense to solve it once and fo= r >> all. >> Thanks >> Laszlo >=20 > Laszlo, >=20 > Defining a PCD bit for DEBUG() AP safety is an excellent suggestion. As= you said, this is a long-standing, recurrent problem which keeps biting re= al platforms, and it would be good to have a solid, platform-independent so= lution. >=20 > I do wonder if there would be a clean way to let a DebugLib instance its= elf declare that AP_DEBUG() is safe. That way a platform would only need t= o override the DebugLib instance in the DSC file, rather than both the inst= ance and the PCD. (I know, I'm nitpicking.) A library can't override PCDs= in its calling modules, of course. I suppose the AP_DEBUG() macro could c= all a new DebugLib entry point to test for AP safety before doing anything = else, say DebugPrintOnApIsSafe(). Or it could even be a global CONST BOOLE= AN defined by the library. But that would require all DebugLib instances t= o change, which is something you were trying to avoid. >=20 > However, it's not always practical to track down all uses of DEBUG(). An= AP can easily call a library routine which uses DEBUG() rather than AP_DEB= UG(), buried under several layers of transitive library dependencies. In o= ther words, it's not always practical to determine ahead of time if a given= DEBUG() call may be done on an AP. I know that AP code runs in a very res= tricted environment and that people who use MpServices are supposed to unde= rstand the repercussions, but it gets very difficult when libraries are inv= olved. :( >=20 > So would a better solution be to modify the common unsafe DebugLib insta= nces to have DebugPrintEnabled() return FALSE on APs? That would probably = require a new BaseLib interface to determine if the caller is running on th= e BSP or an AP. (For IA32/X64 this isn't too hard -- it just needs to chec= k a bit in the local APIC. I have no idea about other architectures.) Tha= t wouldn't solve the problem everywhere -- anyone using a custom DebugLib w= ould have to update it themselves. But it would solve it solidly in the ma= jority of cases. >=20 > Thoughts? For DXE you can use the MpServices protocol to tell if you are on the BSP = or not.=20 https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/MpSe= rvice.h EFI_MP_SERVICES_PROTOCOL.WhoAmI() gets you your ProcessorNumber. EFI_MP_SE= RVICES_PROTOCOL.GetProcessorInfo() returns the ProcessInfoBuffer that lets = you know if you are the BSP. You would want to grab the MpServices protoco= l pointer early in the driver prior to doing any work on the AP.=20 typedef struct { /// /// The unique processor ID determined by system hardware. For IA32 and= X64, /// the processor ID is the same as the Local APIC ID. Only the lower 8 = bits /// are used, and higher bits are reserved. For IPF, the lower 16 bits = contains /// id/eid, and higher bits are reserved. /// UINT64 ProcessorId; /// /// Flags indicating if the processor is BSP or AP, if the processor is = enabled /// or disabled, and if the processor is healthy. Bits 3..31 are reserve= d and /// must be 0. /// /// 
  /// BSP  ENABLED  HEALTH  Description
  /// =3D=3D=3D  =3D=3D=3D=3D=3D=3D=3D  =3D=3D=3D=3D=3D=3D  =3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  ///  0      0       0     Unhealthy Disabled AP.
  ///  0      0       1     Healthy Disabled AP.
  ///  0      1       0     Unhealthy Enabled AP.
  ///  0      1       1     Healthy Enabled AP.
  ///  1      0       0     Invalid. The BSP can never be in the disabled =
state.
  ///  1      0       1     Invalid. The BSP can never be in the disabled =
state.
  ///  1      1       0     Unhealthy Enabled BSP.
  ///  1      1       1     Healthy Enabled BSP.
  ///
/// UINT32 StatusFlag; /// /// The physical location of the processor, including the physical packa= ge number /// that identifies the cartridge, the physical core number within packa= ge, and /// logical thread number within core. /// EFI_CPU_PHYSICAL_LOCATION Location; } EFI_PROCESSOR_INFORMATION; DebugPrinttEnabled() and DebugAssertEnabled() would be needed at a minimum= as I don't think you really want to be ASSERTing on the AP, unless that is= your intent. I think on a lot of platforms end up having these functions b= e based on FixedAtBuild PCDs and the function calls get optimized away. Thu= s it seems like you would want an MP safe version of a given library.=20 This same problem kind of exists for Runtime drivers too. You would not wa= nt to ASSERT or DEBUG print at runtime in a Lib that was not Runtime safe.= =20 Thanks, Andrew Fish > --=20 > Brian J. Johnson > Enterprise X86 Lab >=20 > Hewlett Packard Enterprise >=20 >=20 --Apple-Mail=_F753301B-064E-4669-9468-14885F786039 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 31= , 2019, at 9:34 AM, Brian J. Johnson <brian.johnson@hpe.com> wrote:

On 7/31/19 7:43 AM, Laszlo = Ersek wrote:
(adding Mike)
On 07/31/19 09:35, Eric Dong wrote:
REF: https://bugzilla.tian= ocore.org/show_bug.cgi?id=3D1984

Current d= ebug message brings much restriction for the platform
which u= se this driver.

For PEI and DXE phase, platfor= m mush link base DebugLib (without
using any pei/dxe services= , even for its dependent libraries).

This patc= h default disable this debug message, only open it when
need = to debug the related code.

Signed-off-by: Eric= Dong <eric.dong@intel= .com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <<= a href=3D"mailto:lersek@redhat.com" class=3D"">lersek@redhat.com>
Eric Dong (2):
  UefiCpu= Pkg/RegisterCpuFeaturesLib: Default avoid print.
  = UefiCpuPkg/PiSmmCpuDxeSmm: Default avoid print.

 .../Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c  &n= bsp; | 4 +++-
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c &n= bsp;            = ;            &n= bsp;  | 4 +++-
 2 files changed, 6 insertions(= +), 2 deletions(-)

The basic prob= lem seems to be that APs should not use "thick" services
that= might underlie the DebugLib instance that is picked by the
p= latform. That requirement appears sane to me.
I think I disag= ree with the proposed mitigation though. Reasons:
(a) The mit= igation is duplicated to independent modules.
(b) It is not p= ossible to change the debug mask without modifying C
language= source code.
(c) Passing a zero log mask to DEBUG() on the A= Ps does not guarantee
thread safety:
- The DEBU= G() macro calls DebugPrintEnabled() regardless of the log mask
passed to DEBUG().
- The DEBUG() macro may or may not call = DebugPrintLevelEnabled(),
dependent on architecture & too= lchain.
- Both DebugPrintEnabled() and DebugPrintLevelEnabled= () are DebugLib
interfaces. The library instance may implemen= t them unsafely for APs,
and a zero log mask at the DEBUG cal= l site could not prevent that.
- Finally, DebugPrint() itself= could invoke thread-unsafe logic, before
consulting the log = mask.
I would propose the following, instead:
(= i) Introduce BIT6 for PcdDebugPropertyMask in "MdePkg.dec". The default
value should be zero. The bit stands for "DEBUG is safe to call = on APs".
(ii) Add a macro called AP_DEBUG to <DebugLib.h&g= t;.
This macro should work the same as DEBUG, except it shoul= d do nothing if
BIT6 in PcdDebugProperyMask is clear.
Fetching PcdDebugPropertyMask inside AP_DEBUG() is safe, because:- the PCD can only be fixed-at-build or patchable-in-module (th= erefore
it is safe to read on APs -- no PCD PPI or PCD Protoc= ol is needed);
- PcdDebugPropertyMask is a preexistent PCD th= at *all* existent DebugLib
instances are expected to consume = -- per the API specifications in
<DebugLib.h> --, there= fore no new PCD dependency would be introduced to
DebugLib in= stances.
(iii) Modules that call DEBUG on APs should replace = those calls with
AP_DEBUG. Code that currently calls DEBUG wh= ile running on either BSP or
APs should discriminate those ca= ses from each other, and use AP_DEBUG
explicitly, when it run= s on APs.
As a further refinement, a macro called MP_DEBUG co= uld be introduced
too, with a new initial parameter called "B= sp". If the Bsp parameter is
TRUE, then MP_DEBUG is identical= to DEBUG. Otherwise, MP_DEBUG is
identical to AP_DEBUG. This= way, DEBUG() calls such as described above
wouldn't have to = be split into DEBUG / AP_DEBUG calls; they could be
changed i= nto MP_DEBUG calls (with an extra parameter in the front).
(i= v) platforms can set BIT6 in PcdDebugPropertyMask in DSC files. This
need not be a full platform-level setting: the PCD can be overridde= n in
module scope, just like the DebugLib resolution can be m= odule-scoped.
As an end result, AP_DEBUG messages will disapp= ear by default (safely),
and platforms will have to do extra = work only if they want AP_DEBUG
messages to appear. Otherwise= the change is transparent to platforms.
And, I think that AP= _DEBUG belongs in MdePkg (and not UefiCpuPkg)
because both De= bugLib and EFI_MP_SERVICES_PROTOCOL are declared in
MdePkg. W= hile UefiCpuPkg provides the multiprocessing implementation for
IA32 and X64, the problem is architecture-independent. Furthermore, the<= br class=3D"">problem is a long-standing and recurrent one -- please refer = to commit
81f560498bf1, for example --, so it makes sense to = solve it once and for
all.
Thanks
Laszlo

<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size:= 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; text-align: start; text-indent: 0px; text-transform= : none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px; text-decoration: none; float: none; display: inline !important;" class= = =3D"">Laszlo,

Defining a PCD bit for DEBUG() AP safety is = an excellent suggestion.  As you said, this is a long-standing, recurr= ent problem which keeps biting real platforms, and it would be good to have= a solid, platform-independent solution.

I do wonder if the= re would be a clean way to let a DebugLib instance itself declare that AP_D= EBUG() is safe.  That way a platform would only need to override the D= ebugLib instance in the DSC file, rather than both the instance and the PCD= .  (I know, I'm nitpicking.)  A library can't override PCDs in it= s calling modules, of course.  I suppose the AP_DEBUG() macro could ca= ll a new DebugLib entry point to test for AP safety before doing anything e= lse, say DebugPrintOnApIsSafe().  Or it could even be a global CONST B= OOLEAN defined by the library.  But that would require all DebugLib in= stances to change, which is something you were trying to avoid.

However, it's not always practical to track down all uses of DEBUG()= . An AP can easily call a library routine which uses DEBUG() rather than AP= _DEBUG(), buried under several layers of transitive library dependencies. &= nbsp;In other words, it's not always practical to determine ahead of time i= f a given DEBUG() call may be done on an AP.  I know that AP code runs= in a very restricted environment and that people who use MpServices are su= pposed to understand the repercussions, but it gets very difficult when lib= raries are involved.  :(
=
So would a better solution be= to modify the common unsafe DebugLib instances to have DebugPrintEnabled()= return FALSE on APs?  That would probably require a new BaseLib inter= face to determine if the caller is running on the BSP or an AP.  (For = IA32/X64 this isn't too hard -- it just needs to check a bit in the local A= PIC.  I have no idea about other architectures.)  That wouldn't s= olve the problem everywhere -- anyone using a custom DebugLib would have to= update it themselves.  But it would solve it solidly in the majority = of cases.

=
Thoughts?


<= div>
For DXE you can use the MpServices protocol to tell if you are on = the BSP or not. 


EFI_MP_SERVICES_PROTOCOL.WhoAmI() gets you y= our ProcessorNumber. EFI_MP_SERVICES_PROTOCOL.GetProcessorInfo() returns th= e ProcessInfoBuffer that lets you know if you are the BSP.  You would = want to grab the MpServices protocol pointer early in the driver prior to d= oing any work on the AP. 

/// must be 0.<= td id=3D"L130" class=3D"blob-num js-line-number" data-line-number=3D"130" s= tyle=3D"box-sizing: border-box; padding: 0px 10px; -webkit-user-select: non= e; color: rgba(27, 31, 35, 0.298039); cursor: pointer; font-family: SFMono-= Regular, Consolas, "Liberation Mono", Menlo, monospace; font-size= : 12px; line-height: 20px; min-width: 50px; text-align: right; vertical-ali= gn: top; white-space: nowrap; width: 50px;">
typedef struct {
///
= /// Th= e unique processor ID determined by system hardware. For IA32 and X64,
= /// = the processor ID is the same as the Local APIC ID. Only the lower 8 bits
///= are used, and higher bits are reserved. For IPF, the lower 16 bits contai= ns
//= / id/eid, and higher bits are reserved.
///
UINT64 = ProcessorId;
///
/// Flags indicating if the processor is BSP or AP, i= f the processor is enabled
/// or disabled, and if the processor is healt= hy. Bits 3..31 are reserved and
///
/// <pre><= /td>
/// BSP = ENABLED HEALTH Description
/// =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D =3D=3D= =3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
/// 0 0 0 Unhealthy Disabled AP.
= /// = 0 0 1 Healthy Disabled AP.
/// 0 1 0 Unhea= lthy Enabled AP.
/// 0 1 1 Healthy Enabled AP.
/// 1 = 0 0 Invalid. The BSP can never be in the disabled state.<= /td>
/// 1 = 0 1 Invalid. The BSP can never be in the disabled state.
= /// = 1 1 0 Unhealthy Enabled BSP.
/// 1 1 1 Healt= hy Enabled BSP.
/// </pre>
///
UINT32 St= atusFlag;
//= /
/// The physical location of the processor, including the physical = package number
/// that identifies the cartridge, the physical core num= ber within package, and
/// logical thread number within core.
///<= /td>
EF= I_CPU_PHYSICAL_LOCATION Location;
} EFI_PROCESSOR_INFORMATION;

DebugPrinttEnabled() and DebugAssertEnabled() would be needed at a minim= um as I don't think you really want to be ASSERTing on the AP, unless that = is your intent. I think on a lot of platforms end up having these functions= be based on FixedAtBuild PCDs and the function calls get optimized away. T= hus it seems like you would want an MP safe version of a given library.&nbs= p;

This same problem kind of exists for= Runtime drivers too. You would not want to ASSERT or DEBUG print at runtim= e in a Lib that was not Runtime safe. 

=
Thanks,

Andrew Fish

-- 
Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterp= rise


= --Apple-Mail=_F753301B-064E-4669-9468-14885F786039--