Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block

[Fan, Jeff]

I did not receive the patch 42. I have only gotten 38,39,40,41.

OK, If this mtrr setting stored in ACPI NVS is for CpuS3DataDxe to store into 
SMRAM, that's fine.

Then, another question, what's requirement to save MTRR setting into ACPI NVS 
on this case? And need one PCD to switch on/off it?

Jeff

-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini
Sent: Tuesday, July 28, 2015 2:52 PM
To: Fan, Jeff; Laszlo Ersek; edk2-de...@ml01.01.org
Cc: Chen Fan; Justen, Jordan L
Subject: Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR 
settings to AcpiNVS memory block



On 28/07/2015 08:05, Fan, Jeff wrote:
 Ersek,
 
 I have one comment for PCD PcdCpuSyncMtrrToAcpiNvs.
 
 I knew OvmfPkg implemented LockBox based on ACPI NVS. Saving MTRR setting in 
 AcpiNVS is OK for OvmfPkg.

If I understand correctly what you are saying, the AcpiNVS block is only used 
for communication from CpuDxe to CpuS3DataDxe in patch 42.
CpuS3DataDxe saves the MTRR in SMRAM during SmmReadyToLockEventNotify() and 
PiSmmCpuDxeSmm restores them during S3 resume.  So Laszlo's patches are doing 
exactly the safe thing, even though they are not using LockBox.

 But other platform may want to use more safe solution to save MTRR based on 
 in SMM. 
 
 I think that, for long term, saving MTRR setting by LockBox instead of 
 using ACPI NVS memory directly.  Then, different platforms could 
 provide the different LockBox solutions. For short term, still saving 
 MTRR setting in ACPI NVS in CpuDxe, and removing this PCD. That means 
 we could CpuDxe implementation to use the long term solution in the 
 future and needn't to remove one un-used PCD more.

The PCD is consumed in CPUS3DataDxe.

Paolo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] WFH today (EOM)

[Fan, Jeff]

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] IntelFrameworkModulePkg: GenericBdsLib: set Status before use

[Fan, Jeff]

Reviewed-by: Jeff Fan jeff@intel.com

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, July 24, 2015 7:36 AM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Fan, Jeff
Subject: [PATCH] IntelFrameworkModulePkg: GenericBdsLib: set Status before use

The recent patch titled

  IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3-S3Save() call

has exposed a preexistent bug in the BdsLibBootViaBootOption() function, and 
now the IA32 build of OVMF fails with:

  In function 'BdsLibBootViaBootOption':
  error: 'Status' may be used uninitialized in this function

Namely, we have the following (simplified) data flow:

  //
  // Status and ImageHandle both start out uninitialized
  //

  /* ... */
  ImageHandle = BdsExpandUsbShortFormDevicePath (DevicePath);
  /* ... */

  if (ImageHandle == NULL) {
/* ... */
  }
  if ((ImageHandle == NULL) || (EFI_ERROR(Status))) {
/* ... */
  */

If BdsExpandUsbShortFormDevicePath() returns a non-NULL value, then the second 
if statement will check Status without the function having initialized or 
assigned it.

When BdsExpandUsbShortFormDevicePath() returns non-NULL, Status should be 
EFI_SUCCESS; so let us assign it that value up-front.

Note that the bug existed before the patch

  IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3-S3Save() call

That is, the bug was not introduced, only exposed, by the patch -- in the 
pre-patch state, although the Status variable was set early and 
unconditionally, the error code that it may have carried from the failed 
gEfiAcpiS3SaveProtocolGuid lookup had nothing to do with the second if
statement above.

Cc: Jiewen Yao jiewen@intel.com
Cc: Jeff Fan jeff@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---

Notes:
This is the rare example when a gcc warning catches an actual bug :)

 IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c 
b/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c
index 4b7eca7..68b32f3 100644
--- a/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c
+++ b/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c
@@ -2236,6 +2236,7 @@ BdsLibBootViaBootOption (
   LIST_ENTRYTempBootLists;
   EFI_BOOT_LOGO_PROTOCOL*BootLogo;
 
+  Status= EFI_SUCCESS;
   *ExitDataSize = 0;
   *ExitData = NULL;
 
--
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 6/7] UefiCpuPkg: Add missing PCD usage information in UNI files.

[Fan, Jeff]

Reviewed-by: Jeff Fan jeff@intel.com

-Original Message-
From: Qiu, Shumin 
Sent: Tuesday, July 21, 2015 8:51 PM
To: edk2-devel@lists.01.org
Cc: Qiu, Shumin
Subject: [PATCH 6/7] UefiCpuPkg: Add missing PCD usage information in UNI files.

Cc Jeff Fan jeff@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin shumin@intel.com
---
 UefiCpuPkg/UefiCpuPkg.uni | Bin 3320 - 6586 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni index 
db624f3bc545ec7daf9fae1983e012528ac29edc..727fb6fd49e51a813c72f2e4ed431cb5436f99cb
 100644 GIT binary patch literal 6586 
zcmdUzYj0Xd5QgV-rTK_@};Q~yQx~Ws;a8KkQDib3|3mHQpC*|*kAcuALvB_IY$
zf#Jc+YnP7an4?6XWw~ec9wrXZQ7K{J!N$~}l0j$KGzP7JuRbSQ4XzNodTg@7F
zb!Ts#I7v0OS`7GNnImOtY~koM5#efmk~7^|eQS6Wc+?3B6rnGxsnpd+P^@O^{
zrqokPlDRR~WSuqIVLw-P8?hN*MPlz0|qboesACL{6y*XsP@Kwv{#f%?0Ud1FDOew
ziVVFSvrBq6=-HxQBZP{7Gh~Yr^WZ0Qj?Lt+O{3rZ};Nm7Hfw!x=4w*571c_m3=eI
z_1IAdE!y;SgH~FvL+K(|TUOF6S*~-N2_$nZ70p_XfY;#O_Uh9NW5n~rr(z{52W
zE-9#*)p|qZ2r#vU)G!YLJ(Dz-~~e?q6k{s}B@@SfeJGtFf)3rvQRkYhWJQauC
z9+NE8Q1f5Wg+Q!+Tn%Nqij3TSnCbGN(v(B69OhlO}FfD^w2PZYx(V~tM(;v39O
zvCrm|4f?dy*+CP|O|HIylrw(WKC)8P{=k3b=f`$r?|5(70re7?CZMWsmDUnWJE2qz
zNT1jt-y-db6)qvOLJ4LU8Bqz6k0^=JdKdUguA~DZil*RuX5VGr(aT!!itH#XVh`f
z?2z^nQYGUktbR;Qx~olVRvD`?TGdCrWvo{Ji|-yi(p;Wc9IfKJDB7Q6IhphlSd`(F
z*4*NmlQ)cgYLpqzZYW`xfeNpACR*JE_=M+A?*WSAtr3qUPYt%x_zck~M@Y9)-n;
z*PtU!3rJplOfHP~___NNKPv1@+$oQ3GP}pc`+M%wDBJrY8@I7ZE1ai0_}h?upJTBq
z9(x}AxI(MqZ3_+zi7!ofP^R7lCyn1{WP=eGaNo1{|rurxx`lkDmbjFiZX_b~ww
zqo~uS7jzSoJc`#x(iMgB@?$iMXLqKTe5s5@ci`RnprHt~k6vQeVk9y?3q5X4aIan
z1#wB-_8}q-73?#DXvVOI*PY(WwtlzUUX9-mc=aAOzvTPIYYN=Y-DPTO!bE
zP*)5*hE+d@yhXW-o;PT)7)@m~j-XTjLMGbWVWb`Wi|TeeMtH!TPOt+671DAGg$d
z_=|i(Xv8%q^DZPs(h3wMiUm_?4rN$_URe3gmmEIi~VFIJo^tt~i^D#v_A0WO
z$8QREp`(0L8B(;3;$3DNdB!Yynxh5{-Nw^K9*mCZwIV6C!sz_8F4Ph`dUK9BOX
zL-g#1@Qtf^j4;Q!`}PIzT(k3Vwt?KmsAJb4Bq?N9BC-guIs0wm=SZcNX*16Yeo+
zJ)L0KuX+NB~r=D%jKS-xav^5!)(XSjNe(n~qBse_XciHR6!Yc=5?^5!uaj9%FRp
zRYvggnb3F`H|C%GefByXtKwPx7$k(~EV{}KhV;09Mx+l|I|-+eZuNerp3Wk=Vcx+0
z#;e7-*KR(S_-gg`8m(3{Ve7TRViOLPsF33}U$%LzEuRtjK}LHQfi5!wGmgecyk
zBwqUY=Kl!E*ZTBM((i;Y2cma`!2pjgnA5e5A)f1nMB-SL~=5ZzdxIpM(+QHdX~c~
zM-of)AMF61oGsyI4eEjylI8JLHEbI??($+pK1H?|T^x^Zz98y6MH7D*A5T|FTRr
xTFC!LcN^)ZDIDXd86})KPRqvJ)V+*%-U|6RWS!yzuhj6OL33W-1%Gv{0F68O*Q}k

delta 14
VcmdmG{6lg1tX)$=1RtTZU8J1rz`P

--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 27/52] OvmfPkg: use relaxed AP SMM synchronization mode

[Fan, Jeff]

This method may cause SMI storm easily.

In case, some processors already entered into SMM but did not set present bit. 
SMM BSP will send additional SMI to them and bring them into SMM again after 
they exited from SMM. 
Then new SMM BSP will send additional SMI to old SMM BSP again.

Jeff
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Paolo 
Bonzini
Sent: Monday, October 26, 2015 10:53 AM
To: Laszlo Ersek; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Justen, Jordan L
Subject: Re: [edk2] [PATCH v3 27/52] OvmfPkg: use relaxed AP SMM 
synchronization mode

On 23/10/2015 17:29, Laszlo Ersek wrote:
> I plan to drop this patch, dependent on testing, and on how a new QEMU 
> patch I've written will be received on qemu-devel.

I'm not sure why it can't be fixed within the firmware.  Your patch to QEMU to 
use current_cpu obviously makes sense (that's why it has been merged already 
:)), but otherwise the firmware should adjust to the hardware, not the other 
way round.

Perhaps we can use a new sync mode (a new PCD would be neater, but you'd have 
to pass it to BSPHandler and APHandler) to send the IPI from SMM.  A simple 
implementation of the former would be this:

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 
dd333a1..1be1a4d 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -377,7 +377,7 @@
 !endif
 
 !if $(SMM_REQUIRE) == TRUE
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x02
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|1
 !endif
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index 
9f1ed34..430f1f4 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -383,7 +383,7 @@
 
 [PcdsFixedAtBuild.X64]
 !if $(SMM_REQUIRE) == TRUE
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x02
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|2
 !endif
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index 
c0cc92b..b052806 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -382,7 +382,7 @@
 !endif
 
 !if $(SMM_REQUIRE) == TRUE
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x02
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|2
 !endif
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index b0191cb..7b20e27 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -191,6 +191,29 @@ AllCpusInSmmWithExceptions (  }
 
 
+VOID
+SmmSendSmiToAPs (
+  VOID
+  )
+{
+  UINTN Index;
+
+  ASSERT (mSmmMpSyncData->Counter <= mNumberOfCpus);
+
+  if (mSmmMpSyncData->Counter < mNumberOfCpus) {
+//
+// Send SMI IPIs to bring outside processors in
+//
+for (Index = mMaxNumberOfCpus; Index-- > 0;) {
+  if (!mSmmMpSyncData->CpuData[Index].Present && 
gSmmCpuPrivate->ProcessorInfo[Index].ProcessorId != INVALID_APIC_ID) {
+SendSmiIpi ((UINT32)gSmmCpuPrivate->ProcessorInfo[Index].ProcessorId);
+  }
+}
+  }
+
+  return;
+}
+
 /**
   Given timeout constraint, wait for all APs to arrive, and insure when this 
function returns, no AP will execute normal mode code before
   entering SMM, except SMI disabled APs.
@@ -344,6 +367,16 @@ BSPHandler (
   //
   gSmmCpuPrivate->SmmCoreEntryContext.CurrentlyExecutingCpu = CpuIndex;
   
+  //
+  // Manual AP Sync Mode: SmmControl2DxeTrigger only triggers an SMI  
+ // on the processor that executed it, call all other APs.  Otherwise  
+ // this is the same as Relaxed mode.
+  //
+  if (SyncMode == SmmCpuSyncModeManualAp) {
+SmmSendSmiToAPs();
+  }
+
   //
   // If Traditional Sync Mode or need to configure MTRRs: gather all available 
APs.
   //
@@ -450,12 +482,11 @@ BSPHandler (
   ClearSmi();
 
   //
-  // If Relaxed-AP Sync Mode: gather all available APs after BSP SMM handlers 
are done, and
-  // make those APs to exit SMI synchronously. APs which arrive later will be 
excluded and 
+  // If Relaxed-AP or Manual-AP Sync Mode: gather all available APs 
+ after BSP SMM handlers  // are done, and make those APs to exit SMI 
+ synchronously. APs which arrive later will be
   // will run through freely.
   //
   if (SyncMode != SmmCpuSyncModeTradition && 
!SmmCpuFeaturesNeedConfigureMtrrs()) {
-
 //
 // Lock the counter down and retrieve the number of APs
 //
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
index 71f9b1b..a631811 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
@@ -297,6 +297,7 @@ typedef struct {
 typedef enum {
   SmmCpuSyncModeTradition,
   SmmCpuSyncModeRelaxedAp,
+  SmmCpuSyncModeManualAp,
   SmmCpuSyncModeMax
 } SMM_CPU_SYNC_MODE;
 

Paolo
___
edk2-devel 

Re: [edk2] [Patch 3/3] UefiCpuPkg/CpuDxe: Place APs into protected mode when ExitBootService

[Fan, Jeff]

Laszlo,

I saw your simple patch to handle this case. Thanks! I will review/feedback it 
later.

Yes. On physical hw, Aps will not response SMI if Aps received SMI in WFSI 
state. But Aps will have one pending SMI and will enter into SMM once Aps 
receive Startup IPI.

Form section "Local APIC State After an INIT Reset" as below, the pending SMI 
should be cleared. But I do not verified it.
"Upon receiving an INIT through either of these mechanisms, the processor 
responds by beginning the initialization
process of the processor core and the local APIC."

Thanks!
Jeff

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, October 27, 2015 6:31 AM
To: Kinney, Michael D
Cc: Fan, Jeff; edk2-de...@ml01.01.org; Paolo Bonzini
Subject: Re: [Patch 3/3] UefiCpuPkg/CpuDxe: Place APs into protected mode when 
ExitBootService

On 10/26/15 22:59, Kinney, Michael D wrote:
> Laszlo,
> 
> If an AP is in Wait-for-SIPI state, then the AP should ignore the SMI.  
> One description of this is in Intel(R) 64 and IA-32 Architectures 
> Software Developer's Manual Volume 3C, Section 34.2.

Thanks for the reference -- upon seeing Jeff's commit message, I did think that 
perhaps this had not been implemented in QEMU completely faithfully to physical 
hardware.

I sought to spell out both -- differently wrong -- behaviors that are caused by 
the current exit boot services callback: the spurious wakeup on QEMU (which 
might not be fully faithful to phys hw in its own right), that has nowhere to 
return on RSM, and the potential loss of wakeups on phys hw. (Which was 
described by Jeff in his commit message.)

> If QEMU could evaluate the AP state and not send an SMI to an AP in 
> Wait-forSIPI, then updating SMIs to broadcast to all AP should work 
> for SeaBios and OVMF.  All APs in SeaBios are in Wait-for-SIPI, so the 
> BSP will be the only CPU that receives the SMI.  In OVMF, all APs can 
> be in the HLT loop that Jeff Fan provided a patch for (and I see you 
> have a good update for), so the SMI can be delivered to BSP and all 
> APs.

I'd like to run this idea by Paolo (CC'd). Theoretically I might be able to 
respin my QEMU patch so that it looks at the APs' states right when one of the 
VCPUs writes to APM_CNT. But, as far as I recall, in QEMU it is two separate 
actions to generate / make an interrupt pending, and then to deliver it. 
Filtering out the SMI at generation time might not be the right thing to do. 
Doing it in the delivery / injection code seems possible, but that code is 
super quirky and I don't dare touch it.
(Worse, I think that code might exist separately for TCG (in QEMU) and KVM (in 
the host kernel).)

Also, I'm not sure that simply not sending the SMI when the AP is in 
wait-or-SIPI would be right. The section you referenced has a note like
this:

  [...] If a SMI is received while an application processor is in the
  wait for SIPI mode, the SMI will be pended. The processor then
  responds on receipt of a SIPI by immediately servicing the pended SMI
  and going into SMM before handling the SIPI.

This might not play so well with SeaBIOS -- SeaBIOS will probably not care 
about the pending SMI, but the OS after it might. I'm not sure what an OS is 
expected to do to boot an AP.

Is INIT-SIPI-SIPI a requirement (emphasis on "INIT") for the OS? And would that 
INIT clear the pending SMI "inherited" from SeaBIOS?

I wish we could do something simpler here... I still think that a QEMU command 
line option would be safest. The configuration couldn't be influenced by the 
guest, and responsibility would belong with higher level components (libvirt, 
or human command line user). SMM is pretty specialized already, so keeping the 
current behavior as default, and requiring another QEMU option for broadcasting 
SMIs should be acceptable.

Thanks!
Laszlo

> 
> Best regards,
> 
> Mike
> 
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Monday, October 26, 2015 10:37 AM
>> To: Fan, Jeff; edk2-de...@ml01.01.org
>> Cc: Kinney, Michael D
>> Subject: Re: [Patch 3/3] UefiCpuPkg/CpuDxe: Place APs into protected 
>> mode when ExitBootService
>>
>> On 10/26/15 14:47, Jeff Fan wrote:
>>> In original ExitBootService callback function, we will send INIT IPI 
>>> to all APs and place APs into wait-for-sipi state.
>>
>> Yes.
>>
>>> However, it prevents APs to
>>> response any SMI. As a result, SMM BSP needs to do a specified 
>>> timeout
>> delay
>>> on each SMI.
>>
>> These two sentences are not precise. The problem is not that SMI is 
>> not delivered  to those APs that are in wait-for-sipi.
>>
>> Instead, the problem is that the APs wake from the wait-for-sipi 
>> state, execute the SMI handler,

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Shouldn't use gSmst->CurrentlyExecutingCpu

[Fan, Jeff]

Laszlo,

SmmCoreEntry() is from the following code, and it is just PiSmmCore's 
SmmEntryPoint(). 
  //
  // Invoke SMM Foundation EntryPoint with the processor information context.
  //
  gSmmCpuPrivate->SmmCoreEntry (>SmmCoreEntryContext);

Yes. gSmst->CurrentlyExecutingCpu is not set in PiSmmCpuDxeSmm driver. It is 
set in PiSmmCore driver by the following code.
  //
  // Update SMST using the context
  //
  CopyMem (, SmmEntryContext, sizeof 
(EFI_SMM_ENTRY_CONTEXT));

Thanks!
Jeff
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, October 29, 2015 8:46 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D
Subject: Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Shouldn't use 
gSmst->CurrentlyExecutingCpu

On 10/29/15 09:11, Jeff Fan wrote:
> In ConfigSmmCodeAccessCheck(), we used gSmst->CurrentlyExecutingCpu to 
> get the current SMM BSP. But ConfigSmmCodeAccessCheck() maybe invoked 
> before executing
> SmmCoreEntry() and gSmst->CurrentlyExecutingCpu hasn't been updated to 
> the latest value. Instead, we should use
> gSmmCpuPrivate->SmmCoreEntryContext.CurrentlyExecutingCpu directly.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> index e210c8d..c351875 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> @@ -1386,7 +1386,7 @@ ConfigSmmCodeAccessCheck (
>//
>// Check to see if the Feature Control MSR is supported on this CPU
>//
> -  Index = gSmst->CurrentlyExecutingCpu;
> +  Index = gSmmCpuPrivate->SmmCoreEntryContext.CurrentlyExecutingCpu;
>if (!SmmCpuFeaturesIsSmmRegisterSupported (Index, SmmRegFeatureControl)) {
>  mSmmCodeAccessCheckEnable = FALSE;
>  return;
> @@ -1428,7 +1428,7 @@ ConfigSmmCodeAccessCheck (
>// Enable SMM Code Access Check feature for the APs.
>//
>for (Index = 0; Index < gSmst->NumberOfCpus; Index++) {
> -if (Index != gSmst->CurrentlyExecutingCpu) {
> +if (Index != 
> + gSmmCpuPrivate->SmmCoreEntryContext.CurrentlyExecutingCpu) {
>  
>//
>// Acquire Config SMM Code Access Check spin lock.  The AP will 
> release the
> 

I found precisely one location in the entire codebase where 
"gSmmCpuPrivate->SmmCoreEntryContext.CurrentlyExecutingCpu" is set. The call 
tree is:

BSPHandler()   [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]
  // sets field
  gSmmCpuPrivate->SmmCoreEntryContext.CurrentlyExecutingCpu = CpuIndex;

  PerformRemainingTasks()  [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c]
ConfigSmmCodeAccessCheck()
  // reads the value here

>From that aspect this patch looks correct.

However... I have also found that gSmst->CurrentlyExecutingCpu is *never* set.

Is that a correct observation?

And if it is, shouldn't we rather (or additionally) fix *that*?

The commit message references SmmCoreEntry(). That function doesn't seem to 
exist in edk2.

A field called "SmmCoreEntry" does exist in SMM_CPU_PRIVATE_DATA, and (IIRC) it 
does point to SmmEntryPoint() [MdeModulePkg/Core/PiSmmCore/PiSmmCore.c], after 
registration. But even SmmEntryPoint() does not seem to set 
gSmst->CurrentlyExecutingCpu.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] Add API to manage Local APIC SoftwareEnable

[Fan, Jeff]

I agree with this fix. 

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Kinney
Sent: Thursday, October 29, 2015 11:19 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH 0/2] Add API to manage Local APIC SoftwareEnable

The LocalApicLib does not provide any APIs to manage the Local APIC 
SoftwareEnable state without side effects on other registers.  This feature is 
required by the SourceLevelDebugAgent to make sure the Local APIC is in the 
correct state to use the Local APIC Timer.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>

Michael Kinney (2):
  UefiCpuPkg: LocalApicLib: Add API to set SoftwareEnable bit
  SourceLevelDebugPkg: DebugAgent: Set Local APIC SoftwareEnable

 .../DebugAgent/DebugAgentCommon/DebugTimer.c   |  1 +
 .../DebugAgent/DxeDebugAgent/DxeDebugAgentLib.c|  1 +
 .../DebugAgent/SmmDebugAgent/SmmDebugAgentLib.c|  1 +
 UefiCpuPkg/Include/Library/LocalApicLib.h  | 16 -
 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c | 38 +++---
 .../BaseXApicX2ApicLib/BaseXApicX2ApicLib.c| 38 +++---
 6 files changed, 86 insertions(+), 9 deletions(-)

--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Shouldn't use gSmst->CurrentlyExecutingCpu

[Fan, Jeff]

Laszlo,

Thanks your suggestion. I will add the code in commit log.

Jeff

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, October 29, 2015 10:43 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D
Subject: Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Shouldn't use 
gSmst->CurrentlyExecutingCpu

On 10/29/15 14:17, Fan, Jeff wrote:
> Laszlo,
> 
> SmmCoreEntry() is from the following code, and it is just PiSmmCore's 
> SmmEntryPoint(). 
>   //
>   // Invoke SMM Foundation EntryPoint with the processor information context.
>   //
>   gSmmCpuPrivate->SmmCoreEntry (>SmmCoreEntryContext);
> 
> Yes. gSmst->CurrentlyExecutingCpu is not set in PiSmmCpuDxeSmm driver. It is 
> set in PiSmmCore driver by the following code.
>   //
>   // Update SMST using the context
>   //
>   CopyMem (, SmmEntryContext, sizeof 
> (EFI_SMM_ENTRY_CONTEXT));

I don't understand how that CopyMem()  call is supposed to set 
gSmst->CurrentlyExecutingCpu.

- gSmst points to an EFI_SMM_SYSTEM_TABLE2 object.
- gSmmCoreSmst is an object of the same type.

In the EFI_SMM_SYSTEM_TABLE2 structure, "SmmStartupThisAp" and 
"CurrentlyExecutingCpu" are *sibling* fields. Neither of both is contained in 
the other.

Therefore I don't understand how the above CopyMem() can set the 
CurrentlyExecutingCpu field.

... OMG... The CopyMem() actually *overflows* the SmmStartupThisAp field. That 
field is only used as a start offset into gSmmCoreSmst. EFI_SMM_ENTRY_CONTEXT 
contains a *subset* of the EFI_SMM_SYSTEM_TABLE2 fields, in the same order, and 
with the same sizes:
- SmmStartupThisAp
- CurrentlyExecutingCpu
- NumberOfCpus
- CpuSaveStateSize
- ...

Which is why the CopyMem() works.

I'm sorry to say, but  I think this is one of the ugliest pieces of code I've 
seen in my life. :(

Anyway, what we have now is the following order:

  BSPHandler()
gSmmCpuPrivate->SmmCoreEntryContext.CurrentlyExecutingCpu = CpuIndex;

gSmmCpuPrivate->SmmCoreEntry (>SmmCoreEntryContext);

  CopyMem (, SmmEntryContext, sizeof 
(EFI_SMM_ENTRY_CONTEXT));

PerformRemainingTasks()  [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c]
  ConfigSmmCodeAccessCheck()
... gSmst->CurrentlyExecutingCpu ...

So, I don't understand how the bug is possible. In the commit message you say, 
"ConfigSmmCodeAccessCheck() maybe invoked before executing SmmCoreEntry()". How?

Ah! Now I understand, there is another ConfigSmmCodeAccessCheck() call in 
BSPHandler(), *before* SmmCoreEntry. It depends on 
"mRestoreSmmConfigurationInS3".

Can you please add the following to the commit message:

---
  BSPHandler()
gSmmCpuPrivate->SmmCoreEntryContext.CurrentlyExecutingCpu =
  CpuIndex;

//
// when mRestoreSmmConfigurationInS3 is set:
//
ConfigSmmCodeAccessCheck()
  //
  // reads gSmst->CurrentlyExecutingCpu to early
  //

gSmmCpuPrivate->SmmCoreEntry (
  >SmmCoreEntryContext)
  //
  // sets gSmst->CurrentlyExecutingCpu with CopyMem() too late
  //
  CopyMem (,
SmmEntryContext, sizeof (EFI_SMM_ENTRY_CONTEXT));
---

With that change:

Reviewed-by: Laszlo Ersek <ler...@redhat.com>

Thanks
Laszlo


> 
> Thanks!
> Jeff
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 29, 2015 8:46 PM
> To: Fan, Jeff; edk2-de...@ml01.01.org
> Cc: Kinney, Michael D
> Subject: Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Shouldn't use 
> gSmst->CurrentlyExecutingCpu
> 
> On 10/29/15 09:11, Jeff Fan wrote:
>> In ConfigSmmCodeAccessCheck(), we used gSmst->CurrentlyExecutingCpu 
>> to get the current SMM BSP. But ConfigSmmCodeAccessCheck() maybe 
>> invoked before executing
>> SmmCoreEntry() and gSmst->CurrentlyExecutingCpu hasn't been updated 
>> to the latest value. Instead, we should use
>> gSmmCpuPrivate->SmmCoreEntryContext.CurrentlyExecutingCpu directly.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Jeff Fan <jeff@intel.com>
>> Cc: Michael Kinney <michael.d.kin...@intel.com>
>> Cc: Laszlo Ersek <ler...@redhat.com>
>> ---
>>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
>> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
>> index e210c8d..c351875 100644
>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
>> @@ -1386,7 +1386,7 @@ ConfigSmmCodeAccessCheck (
>>//
>>// Check to see if the Feature Control MSR is supported on this CPU
>>//
>> -  Index = 

Re: [edk2] [PATCH 1/6] UefiCpuPkg/CpuDxe: Don't use gBS->Stall

[Fan, Jeff]

It's good!

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Justen, Jordan L 
Sent: Thursday, October 29, 2015 9:33 AM
To: edk2-devel@lists.01.org
Cc: Justen, Jordan L; Fan, Jeff; Laszlo Ersek
Subject: [PATCH 1/6] UefiCpuPkg/CpuDxe: Don't use gBS->Stall

The CpuDxe driver may run before the gEfiMetronomeArchProtocolGuid protocol is 
installed. gBS->Stall does not work until this arch protocol is installed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
---
 UefiCpuPkg/CpuDxe/CpuMp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c index 
04c2f1f..98fdfdf 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -801,7 +801,7 @@ StartupAllAPs (
   goto Done;
 }
 
-gBS->Stall (gPollInterval);
+MicroSecondDelay (gPollInterval);
 mMpSystemData.Timeout -= gPollInterval;
   }
 
@@ -987,7 +987,7 @@ StartupThisAP (
   return EFI_TIMEOUT;
 }
 
-gBS->Stall (gPollInterval);
+MicroSecondDelay (gPollInterval);
 CpuData->Timeout -= gPollInterval;
   }
 
@@ -1755,7 +1755,7 @@ InitializeMpSupport (
 if (CheckAllAPsSleeping ()) {
   break;
 }
-gBS->Stall (gPollInterval);
+MicroSecondDelay (gPollInterval);
 Timeout += gPollInterval;
   } while (Timeout <= PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds));
   ASSERT (Timeout <= PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds));
--
2.5.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/6] UefiCpuPkg/CpuDxe: Ignore extra APs in the system

[Fan, Jeff]

Jordan,

I think we could ASSERT() if the actually processors number is larger than 
maximum number supported in system. 

Otherwise, send broadcast SMI or IPI may break the system.

Jeff
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
Justen
Sent: Thursday, October 29, 2015 9:33 AM
To: edk2-devel@lists.01.org
Cc: Justen, Jordan L; Laszlo Ersek; Fan, Jeff
Subject: [edk2] [PATCH 2/6] UefiCpuPkg/CpuDxe: Ignore extra APs in the system

The PcdCpuMaxLogicalProcessorNumber specifies the maximum number of logical 
processors which are expected to be seen by the system. If more APs actually 
are available in the system, we should prevent them from being used.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
---
 UefiCpuPkg/CpuDxe/CpuMp.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c index 
98fdfdf..e80835f 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1196,6 +1196,17 @@ WhoAmI (
 }
   }
 
+  if (Index >= mMpSystemData.NumberOfProcessors) {
+//
+// This is not a valid error for the WhoAmI function, but it should never
+// happen from outside the driver. It could only happen if more APs
+// started than the PcdCpuMaxLogicalProcessorNumber was set to. This call
+// would come from ApEntryPointInC, and we use this error to prevent the
+// AP from being used by MP services.
+//
+return EFI_DEVICE_ERROR;
+  }
+
   *ProcessorNumber = Index;
   return EFI_SUCCESS;
 }
@@ -1446,10 +1457,15 @@ ApEntryPointInC (
   VOID
   )
 {
+  EFI_STATUS  Status;
   VOID*   TopOfApStack;
   UINTN   ProcessorNumber;
 
   if (!mAPsAlreadyInitFinished) {
+if (mMpSystemData.NumberOfProcessors >= gMaxLogicalProcessorNumber) {
+  return;
+}
+
 FillInProcessorInformation (FALSE, mMpSystemData.NumberOfProcessors);
 TopOfApStack  = (UINT8*)mApStackStart + gApStackSize;
 mApStackStart = TopOfApStack;
@@ -1461,7 +1477,11 @@ ApEntryPointInC (
 mMpSystemData.NumberOfProcessors++;
 mMpSystemData.NumberOfEnabledProcessors++;
   } else {
-WhoAmI (, );
+Status = WhoAmI (, );
+if (EFI_ERROR (Status)) {
+  return;
+}
+
 //
 // Get the original stack address.
 //
--
2.5.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] OvmfPkg: increase MP services startup timeout

[Fan, Jeff]

Jordan,

CPU ID only could get the max logical processor number supported in current 
socket. It cannot handle multi-sockets case.

Yes. We could promote PcdCpuMaxLogicalProcessorNumber to dynamic type. But we 
need find one reliable way like you said to set it before CPU MP PEI not only 
CPU MP DXE.

Thanks!
Jeff

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
Justen
Sent: Thursday, October 22, 2015 5:42 AM
To: Kinney, Michael D; Laszlo Ersek; Kinney, Michael D
Cc: Alex Williamson; edk2-de...@ml01.01.org; Xiao Guangrong; Eduardo Habkost
Subject: Re: [edk2] [PATCH] OvmfPkg: increase MP services startup timeout

On 2015-10-21 14:19:40, Kinney, Michael D wrote:
> Laszlo,
> 
> We have the PCD that specifies the max CPUs.
> 
>   ## Specifies max supported number of Logical Processors.
>   # @Prompt Configure max supported number of Logical Processors
>   
> gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64|UINT32|0x
> 0002

It would need to be changed to a dynamic PCD.

In terms of determining the number of logical processors, can't the cpuid 
function help? I'm not sure how QEMU handles that though.
(Vaguely I remember something like cpuid only help with a single core... So, if 
QEMU presents as multiple cores, then maybe it can't
help.)

We'd need a reliable way to set the PCD before CpuDxe runs.

-Jordan

> We could exit the wait loop as soon as the number of detected CPUs 
> matches PcdCpuMaxLogicalProcessorNumber.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg: PiSmmCpuDxeSmm: Remove Framework compatibility

[Fan, Jeff]

It's good to me!

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Kinney
Sent: Saturday, October 31, 2015 2:03 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH] UefiCpuPkg: PiSmmCpuDxeSmm: Remove Framework 
compatibility

The PiSmmCpuDxeSmm module is using PcdFrameworkCompatibilitySupport to provide 
compatibility with the SMM support in the IntelFrameworkPkg.
This change removes the Framework compatibility and requires all SMM modules 
that provide SMI handlers to follow the PI Specification.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c   | 60 
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   |  1 -
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |  3 --
 3 files changed, 8 insertions(+), 56 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
index e210c8d..7e4d0d9 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -74,17 +74,10 @@ EFI_SMM_CPU_PROTOCOL  mSmmCpu  = {
   SmmWriteSaveState
 };
 
 EFI_CPU_INTERRUPT_HANDLER   mExternalVectorTable[EXCEPTION_VECTOR_NUMBER];
 
-///
-/// SMM CPU Save State Protocol instance -/// -EFI_SMM_CPU_SAVE_STATE_PROTOCOL 
 mSmmCpuSaveState = {
-  NULL
-};
-
 //
 // SMM stack information
 //
 UINTN mSmmStackArrayBase;
 UINTN mSmmStackArrayEnd;
@@ -528,42 +521,32 @@ SmmRestoreCpu (
 //
 InitializeDebugAgent (DEBUG_AGENT_INIT_THUNK_PEI_IA32TOX64, (VOID 
*), NULL);
   }
 
   //
-  // Do below CPU things for native platform only
+  // Skip initialization if mAcpiCpuData is not valid
   //
-  if (!FeaturePcdGet(PcdFrameworkCompatibilitySupport)) {
+  if (mAcpiCpuData.NumberOfCpus > 0) {
 //
-// Skip initialization if mAcpiCpuData is not valid
+// First time microcode load and restore MTRRs
 //
-if (mAcpiCpuData.NumberOfCpus > 0) {
-  //
-  // First time microcode load and restore MTRRs
-  //
-  EarlyInitializeCpu ();
-}
+EarlyInitializeCpu ();
   }
 
   //
   // Restore SMBASE for BSP and all APs
   //
   SmmRelocateBases ();
 
   //
-  // Do below CPU things for native platform only
+  // Skip initialization if mAcpiCpuData is not valid
   //
-  if (!FeaturePcdGet(PcdFrameworkCompatibilitySupport)) {
+  if (mAcpiCpuData.NumberOfCpus > 0) {
 //
-// Skip initialization if mAcpiCpuData is not valid
+// Restore MSRs for BSP and all APs
 //
-if (mAcpiCpuData.NumberOfCpus > 0) {
-  //
-  // Restore MSRs for BSP and all APs
-  //
-  InitializeCpu ();
-}
+InitializeCpu ();
   }
 
   //
   // Set a flag to restore SMM configuration in S3 path.
   //
@@ -685,17 +668,10 @@ SmmReadyToLockEventNotify (
   // Prevent use of mAcpiCpuData by initialize NumberOfCpus to 0
   //
   mAcpiCpuData.NumberOfCpus = 0;
 
   //
-  // If FrameworkCompatibilitySspport is enabled, then do not copy CPU S3 Data 
into SMRAM
-  //
-  if (FeaturePcdGet (PcdFrameworkCompatibilitySupport)) {
-goto Done;
-  }
-
-  //
   // If PcdCpuS3DataAddress was never set, then do not copy CPU S3 Data into 
SMRAM
   //
   AcpiCpuData = (ACPI_CPU_DATA *)(UINTN)PcdGet64 (PcdCpuS3DataAddress);
   if (AcpiCpuData == 0) {
 goto Done;
@@ -1007,11 +983,10 @@ PiCpuSmmEntry (
   gSmmCpuPrivate->CpuSaveState = (VOID **)AllocatePool (sizeof (VOID *) * 
mMaxNumberOfCpus);
   ASSERT (gSmmCpuPrivate->CpuSaveState != NULL);
 
   mSmmCpuPrivateData.SmmCoreEntryContext.CpuSaveStateSize = 
gSmmCpuPrivate->CpuSaveStateSize;
   mSmmCpuPrivateData.SmmCoreEntryContext.CpuSaveState = 
gSmmCpuPrivate->CpuSaveState;
-  mSmmCpuSaveState.CpuSaveState = (EFI_SMM_CPU_STATE 
**)gSmmCpuPrivate->CpuSaveState;
 
   //
   // Allocate buffer for pointers to array in CPU_HOT_PLUG_DATA.
   //
   mCpuHotPlugData.ApicId = (UINT64 *)AllocatePool (sizeof (UINT64) * 
mMaxNumberOfCpus); @@ -1148,29 +1123,10 @@ PiCpuSmmEntry (
   // Initialize SMM CPU Services Support
   //
   Status = InitializeSmmCpuServices (mSmmCpuHandle);
   ASSERT_EFI_ERROR (Status);
 
-  if (FeaturePcdGet (PcdFrameworkCompatibilitySupport)) {
-//
-// Install Framework SMM Save State Protocol into UEFI protocol database 
for backward compatibility
-//
-Status = SystemTable->BootServices->InstallMultipleProtocolInterfaces (
-  >SmmCpuHandle,
-  ,
-  ,
-  NULL
-  );
-ASSERT_EFI_ERROR (Status);
-//
-// The SmmStartupThisAp service in Framework SMST should always be 
non-null.
-// Update SmmStartupThisAp pointer in PI SMST here so that PI/Framework 
SMM t

Re: [edk2] [Patch 2/2] UefiCpuPkg/CpuDxe: Fix one dead lock issue in ProcessorToIdleState()

[Fan, Jeff]

Laszlo,

Your updating patch looks better. But when I tried it on my platform, Sometime, 
it hang at syncing MTRRs from BSP to Aps. I am investigating it and will 
feedback you later.

Thanks!
Jeff

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, October 28, 2015 8:16 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Justen, Jordan L; Chen Fan
Subject: Re: [Patch 2/2] UefiCpuPkg/CpuDxe: Fix one dead lock issue in 
ProcessorToIdleState()

On 10/28/15 07:42, Jeff Fan wrote:
> There is one dead lock issue between BSP and AP. AP has one logic to 
> enter into Sleep state (hlt) if it found its state is Idle state in one loop.
> In ProcessorToIdleState() function, AP will get current AP state, if 
> its state is Sleep state, then it will go into real sleep(hlt) state.
> The dead lock may happen if BSP found AP state is Sleep state and send 
> INIT-SIPI -SIPI to AP. But AP just acquried the lock to get its state. 
> If AP is reset, the lock will not released correctly.
> This fix is to let AP enter into real sleep(hlt) state immediately 
> after it changes its state is set to Sleep and needn't get lock again.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Chen Fan <chen.fan.f...@cn.fujitsu.com>
> ---
>  UefiCpuPkg/CpuDxe/CpuMp.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c 
> index 3de2aa5..357ee42 100644
> --- a/UefiCpuPkg/CpuDxe/CpuMp.c
> +++ b/UefiCpuPkg/CpuDxe/CpuMp.c
> @@ -1289,14 +1289,18 @@ ProcessorToIdleState (
>GetMpSpinLock (CpuData);
>if (CpuData->State == CpuStateIdle) {
>CpuData->State = CpuStateSleeping;
> +ReleaseMpSpinLock (CpuData);
> +while (TRUE) {
> +  //
> +  // Place AP into cli-hlt loop to handle RSM from SMM case
> +  //
> +  DisableInterrupts ();
> +  CpuSleep ();
> +}
>}
>ReleaseMpSpinLock (CpuData);
>  }
>  
> -if (GetApState (CpuData) == CpuStateSleeping) {
> -  CpuSleep ();
> -}
> -
>  CpuPause ();
>}
>  
> 

I think the idea in this patch is good, but I recommend a *much* more sweeping 
change for this function. From my past multi-threaded programming experience, 
it is always best to hold the lock *by default* in a critical section, and only 
release it *temporarily* while yielding, or invoking a callback, or invoking a 
blocking operation.

- It makes no sense to release and reacquire a mutex or splinlock if our thread 
or CPU has actual, fast work to do, without wanting to yield intentionally.

- For loops especially, this means that the loop body is both *entered* and 
*exited* with the lock held.

- This approach tends to improve throughput and happens to eliminate a *bunch* 
of TOCTTOU races.

Therefore my proposal would be:

> diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c 
> index 98976a1..31c6222 100644
> --- a/UefiCpuPkg/CpuDxe/CpuMp.c
> +++ b/UefiCpuPkg/CpuDxe/CpuMp.c
> @@ -1288,40 +1288,42 @@ ProcessorToIdleState (
>  CpuData->Procedure = NULL;
>}
>CpuData->State = CpuStateIdle;
> -  ReleaseMpSpinLock (CpuData);
>  
>while (TRUE) {
> -GetMpSpinLock (CpuData);
>  ProcedureArgument = CpuData->Parameter;
>  Procedure = CpuData->Procedure;
> -ReleaseMpSpinLock (CpuData);
>  
>  if (Procedure != NULL) {
> -  SetApState (CpuData, CpuStateBusy);
> +  CpuData->State = CpuStateBusy;
> +  ReleaseMpSpinLock (CpuData);
>  
>Procedure ((VOID*) ProcedureArgument);
>  
>GetMpSpinLock (CpuData);
>CpuData->Procedure = NULL;
>CpuData->State = CpuStateFinished;
> -  ReleaseMpSpinLock (CpuData);
>  } else {
>//
>// if no procedure to execution, we simply put AP
>// into sleeping state, and waiting BSP sent SIPI.
>//
> -  GetMpSpinLock (CpuData);
>if (CpuData->State == CpuStateIdle) {
> -  CpuData->State = CpuStateSleeping;
> +CpuData->State = CpuStateSleeping;
> +ReleaseMpSpinLock (CpuData);
> +
> +//
> +// wait for INIT-SIPI-SIPI
> +//
> +while (TRUE) {
> +  DisableInterrupts ();
> +  CpuSleep ();
> +}
>}
> -  ReleaseMpSpinLock (CpuData);
> -}
> -
> -if (GetApState (CpuData) == CpuStateSleeping) {
> -  CpuSleep ();
>  }
>  
> +ReleaseMpSpinLock (CpuData);
>  CpuPause ();
> +GetMpSpinLock (CpuData);
>}
>  
>CpuSleep ();

Thank you,
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 00/19] UefiCpuPkg: Add CPU SMM and SecCore

[Fan, Jeff]

This serial of patches s good to me! Thanks!

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Kinney
Sent: Monday, October 19, 2015 3:45 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH v4 00/19] UefiCpuPkg: Add CPU SMM and SecCore

Laszlo,

I have addressed the MP race conditions and have timeouts configurable using a 
PCD in the CpuDxe module in this revised patch series.  I picked up the patch 
from your series to sync MTRRs.  I have also removed trailing spaces from all 
new files in UefiCpuPkg and any files that were modified in UefiCpuPkg.

I have posted a V4 public branch at:

https://github.com/mdkinney/edk2/tree/AddSmmUefiCpuPkg_V4

Michael Kinney (18):
  UefiCpuPkg: Update CPU MP drivers to support single CPU configuration
  UefiCpuPkg: CpuDxe: Use PCD for AP detection timeout
  UefiCpuPkg: CpuDxe: Wait for APs to enter idle loop
  UefiCpuPkg: Add Cpuid.h include files for CPUID related defines
  UefiCpuPkg: Add SMM Communication PPI and Handler Modules
  UefiCpuPkg: Add PlatformSecLib
  UefiCpuPkg: Add SecCore module
  UefiCpuPkg: Add SecCore module and supporting library class and PCD
  UefiCpuPkg: Add SmmCpuFeaturesLib
  UefiCpuPkg: Add SmmCpuPlatformHookLib
  UefiCpuPkg: Add SMM CPU Service Protocol
  UefiCpuPkg: Add SMRAM Save State include file
  UefiCpuPkg: Add ACPI CPU Data include file
  UefiCpuPkg: Add CPU Hot Plug Data include file
  UefiCpuPkg: Update DEC/DSC files for new includes and libraries
  UefiCpuPkg: Add PiSmmCpuDxeSmm module no IA32/X64 files
  UefiCpuPkg: Add PiSmmCpuDxeSmm module IA32 files
  UefiCpuPkg: Add PiSmmCpuDxeSmm module X64 files

edk2-devel (1):
  UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

 UefiCpuPkg/CpuDxe/ApStartup.c  |4 +-
 UefiCpuPkg/CpuDxe/CpuDxe.c |   26 +
 UefiCpuPkg/CpuDxe/CpuDxe.inf   |5 +-
 UefiCpuPkg/CpuDxe/CpuMp.c  |  141 +-
 UefiCpuPkg/CpuDxe/CpuMp.h  |   13 +
 UefiCpuPkg/CpuMpPei/CpuMpPei.c |   34 +-
 UefiCpuPkg/CpuMpPei/CpuMpPei.h |1 +
 UefiCpuPkg/Include/AcpiCpuData.h   |   71 +
 UefiCpuPkg/Include/CpuHotPlugData.h|   33 +
 UefiCpuPkg/Include/Library/PlatformSecLib.h|   70 +
 UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h |  366 +
 UefiCpuPkg/Include/Library/SmmCpuPlatformHookLib.h |  109 ++
 UefiCpuPkg/Include/Protocol/SmmCpuService.h|  209 +++
 UefiCpuPkg/Include/Register/Cpuid.h|   51 +
 UefiCpuPkg/Include/Register/LocalApic.h|   13 -
 UefiCpuPkg/Include/Register/SmramSaveStateMap.h|  190 +++
 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c |1 +
 .../BaseXApicX2ApicLib/BaseXApicX2ApicLib.c|1 +
 .../PlatformSecLibNull/PlatformSecLibNull.c|   90 ++
 .../PlatformSecLibNull/PlatformSecLibNull.inf  |   37 +
 .../PlatformSecLibNull/PlatformSecLibNull.uni  |  Bin 0 -> 1644 bytes
 .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c  |  562 
 .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf|   39 +
 .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.uni|  Bin 0 -> 1672 bytes
 .../SmmCpuPlatformHookLibNull.c|  108 ++
 .../SmmCpuPlatformHookLibNull.inf  |   40 +
 .../SmmCpuPlatformHookLibNull.uni  |  Bin 0 -> 1604 bytes
 .../PiSmmCommunication/PiSmmCommunicationPei.c |  425 ++
 .../PiSmmCommunication/PiSmmCommunicationPei.inf   |   70 +
 .../PiSmmCommunication/PiSmmCommunicationPei.uni   |  Bin 0 -> 2066 bytes
 .../PiSmmCommunicationPeiExtra.uni |  Bin 0 -> 1370 bytes
 .../PiSmmCommunication/PiSmmCommunicationPrivate.h |   30 +
 .../PiSmmCommunication/PiSmmCommunicationSmm.c |  269 
 .../PiSmmCommunication/PiSmmCommunicationSmm.inf   |   82 ++
 .../PiSmmCommunication/PiSmmCommunicationSmm.uni   |  Bin 0 -> 3004 bytes
 .../PiSmmCommunicationSmmExtra.uni |  Bin 0 -> 1392 bytes
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c  |  491 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c |  486 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.h |  181 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/MpFuncs.S   |  165 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/MpFuncs.asm |  168 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |  132 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Semaphore.c |   48 +
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.S  |  191 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm|  193 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.S  |  911 
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.asm|  738 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.S   |   84 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.asm |   94 ++
 UefiCpuPkg/PiSmmCpuD

Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

[Fan, Jeff]

Paolo,

Thanks reporting this spec issue. We will forward it to SDM owner to address it.

Thanks!
Jeff

-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com] 
Sent: Friday, October 16, 2015 4:38 PM
To: Yao, Jiewen; Fan, Jeff; Laszlo Ersek; edk2-de...@ml01.01.org
Cc: Kinney, Michael D
Subject: Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute 
RSM from 64-bit mode



On 16/10/2015 09:41, Yao, Jiewen wrote:
> Hello According to "IA32 SDM, page 1428, 4-330 Vol. 2B, RSM?Resume 
> from System Management Mode", I do not find word say: 64bit mode is 
> invalid. Would you please point out where you find "RSM is invalid in 
> 64-bit mode "?

It's in the heading.  It says

64-bit mode   Invalid
Compat/Leg mode   Valid

Paolo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

[Fan, Jeff]

Thanks Laszlo,

If there is some confusion in SDM, we could inform SDM owner to make a update.

Thanks!
Jeff

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, October 16, 2015 2:25 AM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Paolo Bonzini
Subject: Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute 
RSM from 64-bit mode

On 10/15/15 03:31, Fan, Jeff wrote:
> Ersek & Bonzini,
> 
> From SDM 34.5.2, SMI Handler Operating Mode Switching.
> "Any required change to operating mode is performed by the RSM 
> instruction; there is no need for the SMI handler to change modes explicitly 
> prior to executing RSM."

I believe Paolo based the statement "According to Intel this is invalid"
on another location in the Intel SDM. So maybe there's a contradiction in the 
SDM somewhere -- I don't know the exact place Paolo may have had in mind.

Either way, if you guys can agree on the correct interpretation, we can 
certainly drop this patch.

Thanks!
Laszlo

> So, I don't think we need to go back to 32-bit PM before RSM.
> 
> Thanks!
> Jeff
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Laszlo Ersek
> Sent: Thursday, October 15, 2015 6:26 AM
> To: edk2-de...@ml01.01.org
> Cc: Kinney, Michael D
> Subject: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not 
> execute RSM from 64-bit mode
> 
> From: Paolo Bonzini <pbonz...@redhat.com>
> 
> According to Intel this is invalid.  Go back to 32-bit protected mode and 
> clear EFER.LME before executing RSM.
> 
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
> ---
> 
> Notes:
> v3:
> - New in v3, but included only for completeness here. This is a
>   correction from Paolo for Mike's series "[edk2] [PATCH 0/7]
>   UefiCpuPkg: Add CPU SMM and SecCore".
> 
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S   | 13 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm | 13 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S| 13 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm  | 13 +
>  4 files changed, 52 insertions(+)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
> index 8315593..0f1cab6 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
> @@ -212,6 +212,19 @@ L1:
>  .byte   0x48, 0x89, 0x0d# mov [rip + disp32], rcx
>  .long   SSM_DR6 - (. + 4 - _SmiEntryPoint + 0x8000)
>  L2:
> +
> +pushq   $PROTECT_MODE_CS
> +pushq   $L3
> +lretq
> +L3:
> +movq%cr0, %rbx
> +btrl$31, %ebx
> +movq%rbx, %cr0
> +movl$0xc080, %ecx
> +rdmsr
> +andb$0xfe,%ah
> +wrmsr
> +
>  rsm
>  
>  ASM_PFX(gcSmiHandlerSize):.word  . - _SmiEntryPoint
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
> index a1a7d3e..99eb403 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
> @@ -214,6 +214,19 @@ _SmiHandler:
>  DB  48h, 89h, 0dh   ; mov [rip + disp32], rcx
>  DD  SSM_DR6 - ($ + 4 - _SmiEntryPoint + 8000h)
>  @2:
> +
> +pushPROTECT_MODE_CS
> +push@3
> +retfq
> +@3:
> +mov rbx, cr0
> +btr ebx, 31
> +mov cr0, rbx
> +mov ecx, 0c080h
> +rdmsr
> +and ah, 0feh
> +wrmsr
> +
>  rsm
>  
>  gcSmiHandlerSizeDW  $ - _SmiEntryPoint
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
> index 5ace1a6..fc7c2f9 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
> @@ -32,6 +32,7 @@ ASM_GLOBAL   ASM_PFX(mSmmRelocationOriginalAddressPtr32)
>  ASM_GLOBAL   ASM_PFX(gSmmInitStack)
>  ASM_GLOBAL   ASM_PFX(gcSmiInitGdtr)
>  
> +.equPROTECT_MODE_CS, 0x08
>  
>  .text
>  
> @@ -89,6 +90,18 @@ ASM_PFX(gSmmInitStack):  .space  8
>  movdqa  0x40(%rsp), %xmm4
>  movdqa  0x50(%rsp), %xmm5
>  
> +pushq   $PROTECT_MODE_CS # push 32-bit CS
> +pushq   $L3
> +lretq
> +L3:
> +movq%cr0, %rbx# get out of long mode
> +btrl$31, %ebx
> +movq%rbx, %cr0
> +movl$0xc080, %ecx
> +rdmsr
> +andb$0xfe,%ah
> +wrm

Re: [edk2] [PATCH v2 00/16] UefiCpuPkg: Add CPU SMM and SecCore

[Fan, Jeff]

It's good!

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Kinney, Michael D 
Sent: Friday, October 16, 2015 10:54 AM
To: Kinney, Michael D; edk2-devel@lists.01.org; Fan, Jeff
Cc: Paolo Bonzini; Laszlo Ersek
Subject: RE: [edk2] [PATCH v2 00/16] UefiCpuPkg: Add CPU SMM and SecCore

Hi Jeff,

I have addressed the feedback you sent on code style issues.  

1) Fix function header comment blocks.  
2) Added missing .h files to PisSmmCpuDxeSmm INF file.

I have posted a V3 public branch with your feedback incorporated at:

https://github.com/mdkinney/edk2/tree/AddSmmUefiCpuPkg_V3

Please review and let me know if I missed any of the issues.

Thanks,

Mike

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

[Fan, Jeff]

Ersek & Bonzini,

>From SDM 34.5.2, SMI Handler Operating Mode Switching.
"Any required change to operating mode is performed by the RSM instruction; 
there is no need for the SMI
handler to change modes explicitly prior to executing RSM."

So, I don't think we need to go back to 32-bit PM before RSM.

Thanks!
Jeff
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Thursday, October 15, 2015 6:26 AM
To: edk2-de...@ml01.01.org
Cc: Kinney, Michael D
Subject: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM 
from 64-bit mode

From: Paolo Bonzini 

According to Intel this is invalid.  Go back to 32-bit protected mode and clear 
EFER.LME before executing RSM.

Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
---

Notes:
v3:
- New in v3, but included only for completeness here. This is a
  correction from Paolo for Mike's series "[edk2] [PATCH 0/7]
  UefiCpuPkg: Add CPU SMM and SecCore".

 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S   | 13 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm | 13 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S| 13 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm  | 13 +
 4 files changed, 52 insertions(+)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
index 8315593..0f1cab6 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
@@ -212,6 +212,19 @@ L1:
 .byte   0x48, 0x89, 0x0d# mov [rip + disp32], rcx
 .long   SSM_DR6 - (. + 4 - _SmiEntryPoint + 0x8000)
 L2:
+
+pushq   $PROTECT_MODE_CS
+pushq   $L3
+lretq
+L3:
+movq%cr0, %rbx
+btrl$31, %ebx
+movq%rbx, %cr0
+movl$0xc080, %ecx
+rdmsr
+andb$0xfe,%ah
+wrmsr
+
 rsm
 
 ASM_PFX(gcSmiHandlerSize):.word  . - _SmiEntryPoint
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
index a1a7d3e..99eb403 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
@@ -214,6 +214,19 @@ _SmiHandler:
 DB  48h, 89h, 0dh   ; mov [rip + disp32], rcx
 DD  SSM_DR6 - ($ + 4 - _SmiEntryPoint + 8000h)
 @2:
+
+pushPROTECT_MODE_CS
+push@3
+retfq
+@3:
+mov rbx, cr0
+btr ebx, 31
+mov cr0, rbx
+mov ecx, 0c080h
+rdmsr
+and ah, 0feh
+wrmsr
+
 rsm
 
 gcSmiHandlerSizeDW  $ - _SmiEntryPoint
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
index 5ace1a6..fc7c2f9 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
@@ -32,6 +32,7 @@ ASM_GLOBAL   ASM_PFX(mSmmRelocationOriginalAddressPtr32)
 ASM_GLOBAL   ASM_PFX(gSmmInitStack)
 ASM_GLOBAL   ASM_PFX(gcSmiInitGdtr)
 
+.equPROTECT_MODE_CS, 0x08
 
 .text
 
@@ -89,6 +90,18 @@ ASM_PFX(gSmmInitStack):  .space  8
 movdqa  0x40(%rsp), %xmm4
 movdqa  0x50(%rsp), %xmm5
 
+pushq   $PROTECT_MODE_CS # push 32-bit CS
+pushq   $L3
+lretq
+L3:
+movq%cr0, %rbx# get out of long mode
+btrl$31, %ebx
+movq%rbx, %cr0
+movl$0xc080, %ecx
+rdmsr
+andb$0xfe,%ah
+wrmsr
+
 rsm
 
 ASM_PFX(gcSmmInitTemplate):
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm
index 25a0447..68540a6 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm
@@ -32,6 +32,8 @@ EXTERNDEF   mSmmRelocationOriginalAddressPtr32:DWORD
 EXTERNDEF   gSmmInitStack:QWORD
 EXTERNDEF   gcSmiInitGdtr:FWORD
 
+PROTECT_MODE_CS EQU 08h
+
 .code
 
 gcSmiInitGdtr   LABEL   FWORD
@@ -88,6 +90,17 @@ gSmmInitStack   DQ  ?
 movdqa  xmm4, [rsp + 40h]
 movdqa  xmm5, [rsp + 50h]
 
+pushPROTECT_MODE_CS
+push@3
+retfq
+@3:
+mov rbx, cr0
+btr ebx, 31
+mov cr0, rbx
+mov ecx, 0c080h
+rdmsr
+and ah, 0feh
+wrmsr
 rsm
 SmmStartup  ENDP
 
--
1.8.3.1


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 02/41] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Saturday, October 10, 2015 5:58 AM
To: edk2-de...@ml01.01.org
Cc: Fan, Jeff; Chen Fan; Justen, Jordan L; Kinney, Michael D
Subject: [PATCH v2 02/41] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

The

  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuArchDxe

driver applies any MTRR changes to APs, if the EFI_MP_SERVICES_PROTOCOL is 
available. We should do the same.

Additionally, the broadcast should occur at MP startup as well, not only when 
MTRR settings are changed. The inspiration is taken from

  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/

(see the EarlyMpInit() function and its call sites in "ProcessorConfig.c").

Cc: Jeff Fan <jeff@intel.com>
Cc: Chen Fan <chen.fan.f...@cn.fujitsu.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Michael Kinney <michael.d.kin...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
---

Notes:
v2:
- This patch replaces the following patches from v1:
  - UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory
block
  - UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs
  - UefiCpuPkg: CpuDxe: sync MTRR settings to APs at MP startup
  - UefiCpuPkg: CpuDxe: provide EFI_MP_SERVICES_PROTOCOL when there's no
AP

  The first v1 patch was deemed inappropriate for general use, and Mike
  suggested a good alternative for OVMF (=> grab MTRR settings in
  CpuS3DataDxe at EndOfDxe).

  The second and third v1 patches are now squashed together into this v2
  patch; they are small and belong together logically.

  The fourth v1 patch is redundant now; the same has been covered by
  Mike.

 UefiCpuPkg/CpuDxe/CpuMp.h  | 13   UefiCpuPkg/CpuDxe/CpuDxe.c | 26 
+++  UefiCpuPkg/CpuDxe/CpuMp.c  | 34 +++-
 3 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.h b/UefiCpuPkg/CpuDxe/CpuMp.h index 
d2866e4..503f3ae 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.h
+++ b/UefiCpuPkg/CpuDxe/CpuMp.h
@@ -643,5 +643,18 @@ ResetApStackless (
   IN UINT32 ProcessorId
   );
 
+/**
+  A minimal wrapper function that allows MtrrSetAllMtrrs() to be passed 
+to
+  EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() as Procedure.
+
+  @param[in] Buffer  Pointer to an MTRR_SETTINGS object, to be passed to
+ MtrrSetAllMtrrs().
+**/
+VOID
+EFIAPI
+SetMtrrsFromBuffer (
+  IN VOID *Buffer
+  );
+
 #endif // _CPU_MP_H_
 
diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c index 
c9df4e1..daf97bd 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -350,6 +350,9 @@ CpuSetMemoryAttributes (  {
   RETURN_STATUS Status;
   MTRR_MEMORY_CACHE_TYPECacheType;
+  EFI_STATUSMpStatus;
+  EFI_MP_SERVICES_PROTOCOL  *MpService;
+  MTRR_SETTINGS MtrrSettings;
 
   if (!IsMtrrSupported ()) {
 return EFI_UNSUPPORTED;
@@ -405,6 +408,29 @@ CpuSetMemoryAttributes (
  CacheType
  );
 
+  if (!RETURN_ERROR (Status)) {
+MpStatus = gBS->LocateProtocol (
+  ,
+  NULL,
+  (VOID **)
+  );
+//
+// Synchronize the update with all APs
+//
+if (!EFI_ERROR (MpStatus)) {
+  MtrrGetAllMtrrs ();
+  MpStatus = MpService->StartupAllAPs (
+  MpService,  // This
+  SetMtrrsFromBuffer, // Procedure
+  TRUE,   // SingleThread
+  NULL,   // WaitEvent
+  0,  // TimeoutInMicrosecsond
+  ,  // ProcedureArgument
+  NULL// FailedCpuList
+  );
+  ASSERT (MpStatus == EFI_SUCCESS || MpStatus == EFI_NOT_STARTED);
+}
+  }
   return (EFI_STATUS) Status;
 }
 
diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c index 
da3686e..fbe43f5 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1626,6 +1626,22 @@ ExitBootServicesCallback (  }
 
 /**
+  A minimal wrapper function that allows MtrrSetAllMtrrs() to be passed 
+ to
+  EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() as Procedure.
+
+  @param[in] Buffer  Pointer to an MTRR_SETTINGS object, to be passed to
+ MtrrSetAllMtrrs().
+**/
+VOID
+EFIAPI
+SetMtrrsFromBuffer (
+  IN VOID *Buffer
+  )
+{
+  MtrrSetAllMtrrs (Buffer);
+}
+
+/**
   Initialize Multi-processor support.
 
 **/
@@ -1634,7 +1650,8 @@ InitializeMpSupport (
   VOID
   )
 {
-  EFI_STATUS Status;
+  EFI_STATUSStatus;
+  MTRR_SETTINGS MtrrSettings;
 
   gMaxLogicalProcessorNumb

Re: [edk2] [Patch v2 00/13] UefiCpuPkg/MtrrLib: Add API MtrrSetMemoryAttributeInMtrrSettings()

[Fan, Jeff]

Agree. I will fix them in v3 patches.

-Original Message-
From: Tian, Feng 
Sent: Wednesday, November 18, 2015 8:42 AM
To: Fan, Jeff; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: RE: [edk2] [Patch v2 00/13] UefiCpuPkg/MtrrLib: Add API 
MtrrSetMemoryAttributeInMtrrSettings()

I found many function comments are mismatch with function parameters.

For example,
@param  Attributes The bit mask of attributes to set for the memory 
region.
+MtrrSetMemoryAttributeInMtrrSettings (
+  ...
+  IN MTRR_MEMORY_CACHE_TYPE  Attribute
+  );

+
+  @param  MtrrSettings   A buffer holding all MTRRs content.
+
+**/
+VOID
+WriteFixedMtrrValue (
+  IN MTRR_SETTINGS  *MtrrSetting, OPTIONAL

Could you fix them?

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff Fan
Sent: Monday, November 16, 2015 16:34
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch v2 00/13] UefiCpuPkg/MtrrLib: Add API 
MtrrSetMemoryAttributeInMtrrSettings()

Adds new API MtrrSetMemoryAttributeInMtrrSettings() in MtrrLib.h. It is use to 
program MTRRs register value into the input MTRRs setting buffer instead of 
program MTRRs MSR registers.

If platform wants to program more than one MTRR, it could use this API to 
improve program performance.

The V2 patch has the following updating.

Move the updating on MtrrGetMemoryAttribute() from patch 10/13 to patch 9/13.

Jeff Fan (13):
  UefiCpuPkg/MtrrLib: Add API MtrrSetMemoryAttributeInMtrrSettings()
  UefiCpuPkg/MtrrLib: Add read/write MTRR worker functions
  UefiCpuPkg/MtrrLib: Add worker function to get default MTRR cache type
  UefiCpuPkg/MtrrLib: Support program Fixed MTRRs into setting buffer
  UefiCpuPkg/MtrrLib: Add worker function to get memory attributes
  UefiCpuPkg/MtrrLib: Support invalid variable MTRRs by setting buffer
  UefiCpuPkg/MtrrLib: Support program Variable MTRRs into setting buffer
  UefiCpuPkg/MtrrLib: Support get memory cache type from setting buffer
  UefiCpuPkg/MtrrLib: Add worker function to getthe memory cache type
  UefiCpuPkg/MtrrLib: Use worker functions to access MTRRs register
  UefiCpuPkg/MtrrLib: Add worker function to set memory attributes
  UefiCpuPkg/MtrrLib: Add worker function to print MTRRs setting
  UefiCpuPkg/MtrrLib: Add MtrrSetMemoryAttributeInMtrrSettings()

 UefiCpuPkg/Include/Library/MtrrLib.h |   31 +-
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 1180 ++
 2 files changed, 808 insertions(+), 403 deletions(-)

--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/1] BaseTools: sync BaseTools from main trunk r18579.

[Fan, Jeff]

Thanks. My compare tool skipped the build directory. I think I need to use git 
to sync all patches. :-)

Reviewed-By:  Jeff Fan <jeff@intel.com>

-Original Message-
From: Mike Maslenkin [mailto:mike.maslen...@gmail.com] 
Sent: Wednesday, December 02, 2015 11:17 PM
To: edk2-de...@ml01.01.org
Cc: Mike Maslenkin; Fan, Jeff
Subject: [PATCH 1/1] BaseTools: sync BaseTools from main trunk r18579.

This patch fixes incomplete merge of multiple workspaces support.
Without this patch build fails with error similar to:

~/sources/edk2> build -p MdePkg/MdePkg.dsc -t GCC48 -a X64

Build environment: Linux-3.16.7-24-desktop-x86_64-with-SuSE-13.2-x86_64
Build start time: 17:15:43, Dec.02 2015

WORKSPACE= /home/user/sources/edk2
ECP_SOURCE   = /home/user/sources/edk2/EdkCompatibilityPkg
EDK_SOURCE   = /home/user/sources/edk2/EdkCompatibilityPkg
EFI_SOURCE   = /home/user/sources/edk2/EdkCompatibilityPkg
EDK_TOOLS_PATH   = /home/user/sources/edk2/BaseTools

build.py...
 : error C0DE: Unknown fatal error when processing 
[/home/user/sources/edk2/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf]

(Please send email to edk2-de...@lists.sourceforge.net for help, attaching 
following call stack trace!)

(Python 2.7.8 on linux2) Traceback (most recent call last):
  File 
"/home/user/sources/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
 line 2033, in Main
MyBuild.Launch()
  File 
"/home/user/sources/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
 line 1788, in Launch
self._MultiThreadBuildPlatform()
  File 
"/home/user/sources/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
 line 1583, in _MultiThreadBuildPlatform
self.Progress
  File "/home/user/sources/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", 
line 175, in __new__
if not AutoGenObject._Init(Workspace, MetaFile, Target, Toolchain, Arch, 
*args, **kwargs):
  File "/home/user/sources/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", 
line 355, in _Init
Pkgs = list(PkgSet) + list(PGen.PackageList)
  File "/home/user/sources/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", 
line 1484, in _GetPackageList
for La in self.LibraryAutoGenList:
  File "/home/user/sources/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", 
line 1594, in _GetLibraryAutoGenList
self._GetAutoGenObjectList()
  File "/home/user/sources/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", 
line 1575, in _GetAutoGenObjectList
self.MetaFile
  File "/home/user/sources/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", 
line 175, in __new__
if not AutoGenObject._Init(Workspace, MetaFile, Target, Toolchain, Arch, 
*args, **kwargs):
  File "/home/user/sources/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", 
line 2199, in _Init
self.SourceDir = mws.relpath(self.SourceDir, self.WorkspaceDir)
  File 
"/home/user/sources/edk2/BaseTools/Source/Python/Common/MultipleWorkspace.py", 
line 94, in relpath
for Pkg in cls.PACKAGES_PATH:
TypeError: 'NoneType' object is not iterable

- Failed -
Build end time: 17:15:44, Dec.02 2015
Build total time: 00:00:01

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Mike Maslenkin <mike.maslen...@gmail.com>
CC: Fan, Jeff <jeff@intel.com>
---
 BaseTools/Source/Python/build/BuildReport.py |  5 +++--
 BaseTools/Source/Python/build/build.py   | 16 +++-
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index 264607b00360..60e976c169a1 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -41,6 +41,7 @@ from Common.DataType import TAB_BRG_PCD  from Common.DataType 
import TAB_BRG_LIBRARY  from Common.DataType import TAB_BACK_SLASH  from 
Common.LongFilePathSupport import OpenLongFilePath as open
+from Common.MultipleWorkspace import MultipleWorkspace as mws
 
 ## Pattern to extract contents in EDK DXS files  gDxsDependencyPattern = 
re.compile(r"DEPENDENCY_START(.+)DEPENDENCY_END", re.DOTALL) @@ -1255,7 +1256,7 
@@ class FdRegionReport(object):
 for Pa in Wa.AutoGenObjectList:
 for ModuleKey in Pa.Platform.Modules:
 M = Pa.Platform.Modules[ModuleKey].M
-InfPath = os.path.join(Wa.WorkspaceDir, M.MetaFile.File)
+InfPath = mws.join(Wa.WorkspaceDir, M.MetaFile.File)
 self._GuidsDb[M.Guid.upper()] = "%s (%s)" % 
(M.Module.BaseName, InfPath)
 
 #
@@ -1277,7 +1278,7 @@ class FdRegionReport(object):
 Guid = 
GuidStructureByteArrayToGuidString(GuidValue).upper()
 for Section in Ffs.SectionList:
 try:
- 

Re: [edk2] [Patch 4/4] SourceLevelDebugPkg: Correct gEfiDebugAgentGuid usage in DxeDebugAgentLib

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Tuesday, December 15, 2015 1:45 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 4/4] SourceLevelDebugPkg: Correct gEfiDebugAgentGuid 
usage in DxeDebugAgentLib

DxeDebugAgentLib instance produces gEfiDebugAgentGuid system table.
Its usage should be PRODUCES instead of SOMETIMES_PRODUCES.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming@intel.com>
---
 SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf 
b/SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
index 7ed5f55..8894a04 100644
--- a/SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
+++ b/SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
@@ -81,7 +81,7 @@
   MemoryAllocationLib
 
 [Guids]
-  ## SOMETIMES_PRODUCES ## SystemTable
+  ## PRODUCES ## SystemTable
   ## CONSUMES ## HOB
   gEfiDebugAgentGuid
   ## SOMETIMES_CONSUMES ## SystemTable
-- 
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 09/20] IntelFrameworkPkg: Convert all .uni files to utf-8

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Justen, Jordan L 
Sent: Saturday, December 05, 2015 4:13 AM
To: edk2-devel@lists.01.org
Cc: Justen, Jordan L; Kinney, Michael D; Fan, Jeff
Subject: [PATCH v2 09/20] IntelFrameworkPkg: Convert all .uni files to utf-8

To convert these files I ran:

$ python3 BaseTools/Scripts/ConvertUni.py IntelFrameworkPkg

Cc: Michael D Kinney <michael.d.kin...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 IntelFrameworkPkg/IntelFrameworkPkg.uni   | Bin 1930 -> 964 bytes
 IntelFrameworkPkg/IntelFrameworkPkgExtra.uni  | Bin 1358 -> 678 bytes
 .../Library/DxeIoLibCpuIo/DxeIoLibCpuIo.uni   | Bin 1996 -> 997 bytes
 .../DxeSmmDriverEntryPoint/DxeSmmDriverEntryPoint.uni | Bin 1850 -> 924 bytes
 .../Library/FrameworkUefiLib/FrameworkUefiLib.uni | Bin 2616 -> 1307 bytes
 .../Library/PeiHobLibFramework/PeiHobLib.uni  | Bin 2384 -> 1191 bytes
 .../PeiSmbusLibSmbusPpi/PeiSmbusLibSmbusPpi.uni   | Bin 1734 -> 866 bytes
 7 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/IntelFrameworkPkg/IntelFrameworkPkg.uni 
b/IntelFrameworkPkg/IntelFrameworkPkg.uni
index b358886..9b63fd4 100644
Binary files a/IntelFrameworkPkg/IntelFrameworkPkg.uni and 
b/IntelFrameworkPkg/IntelFrameworkPkg.uni differ diff --git 
a/IntelFrameworkPkg/IntelFrameworkPkgExtra.uni 
b/IntelFrameworkPkg/IntelFrameworkPkgExtra.uni
index 77e969c..ca96cc8 100644
Binary files a/IntelFrameworkPkg/IntelFrameworkPkgExtra.uni and 
b/IntelFrameworkPkg/IntelFrameworkPkgExtra.uni differ diff --git 
a/IntelFrameworkPkg/Library/DxeIoLibCpuIo/DxeIoLibCpuIo.uni 
b/IntelFrameworkPkg/Library/DxeIoLibCpuIo/DxeIoLibCpuIo.uni
index 06f0aef..b2a4b4a 100644
Binary files a/IntelFrameworkPkg/Library/DxeIoLibCpuIo/DxeIoLibCpuIo.uni and 
b/IntelFrameworkPkg/Library/DxeIoLibCpuIo/DxeIoLibCpuIo.uni differ diff --git 
a/IntelFrameworkPkg/Library/DxeSmmDriverEntryPoint/DxeSmmDriverEntryPoint.uni 
b/IntelFrameworkPkg/Library/DxeSmmDriverEntryPoint/DxeSmmDriverEntryPoint.uni
index 0965afc..5042026 100644
Binary files 
a/IntelFrameworkPkg/Library/DxeSmmDriverEntryPoint/DxeSmmDriverEntryPoint.uni 
and 
b/IntelFrameworkPkg/Library/DxeSmmDriverEntryPoint/DxeSmmDriverEntryPoint.uni 
differ diff --git 
a/IntelFrameworkPkg/Library/FrameworkUefiLib/FrameworkUefiLib.uni 
b/IntelFrameworkPkg/Library/FrameworkUefiLib/FrameworkUefiLib.uni
index 5ea7cae..8643521 100644
Binary files a/IntelFrameworkPkg/Library/FrameworkUefiLib/FrameworkUefiLib.uni 
and b/IntelFrameworkPkg/Library/FrameworkUefiLib/FrameworkUefiLib.uni differ 
diff --git a/IntelFrameworkPkg/Library/PeiHobLibFramework/PeiHobLib.uni 
b/IntelFrameworkPkg/Library/PeiHobLibFramework/PeiHobLib.uni
index f591416..6072750 100644
Binary files a/IntelFrameworkPkg/Library/PeiHobLibFramework/PeiHobLib.uni and 
b/IntelFrameworkPkg/Library/PeiHobLibFramework/PeiHobLib.uni differ diff --git 
a/IntelFrameworkPkg/Library/PeiSmbusLibSmbusPpi/PeiSmbusLibSmbusPpi.uni 
b/IntelFrameworkPkg/Library/PeiSmbusLibSmbusPpi/PeiSmbusLibSmbusPpi.uni
index 6a4ae14..8f5d426 100644
Binary files 
a/IntelFrameworkPkg/Library/PeiSmbusLibSmbusPpi/PeiSmbusLibSmbusPpi.uni and 
b/IntelFrameworkPkg/Library/PeiSmbusLibSmbusPpi/PeiSmbusLibSmbusPpi.uni differ
--
2.6.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 19/20] UefiCpuPkg: Convert all .uni files to utf-8

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Justen, Jordan L 
Sent: Saturday, December 05, 2015 4:14 AM
To: edk2-devel@lists.01.org
Cc: Justen, Jordan L; Fan, Jeff
Subject: [PATCH v2 19/20] UefiCpuPkg: Convert all .uni files to utf-8

To convert these files I ran:

$ python3 BaseTools/Scripts/ConvertUni.py UefiCpuPkg

Cc: Jeff Fan <jeff@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 UefiCpuPkg/CpuDxe/CpuDxe.uni| Bin 1756 -> 877 bytes
 UefiCpuPkg/CpuDxe/CpuDxeExtra.uni   | Bin 1352 -> 675 bytes
 UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.uni  | Bin 1952 -> 975 bytes
 UefiCpuPkg/CpuIo2Dxe/CpuIo2DxeExtra.uni | Bin 1344 -> 671 bytes
 UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.uni  | Bin 1972 -> 985 bytes
 UefiCpuPkg/CpuIo2Smm/CpuIo2SmmExtra.uni | Bin 1332 -> 665 bytes
 UefiCpuPkg/CpuIoPei/CpuIoPei.uni| Bin 1896 -> 947 bytes
 UefiCpuPkg/CpuIoPei/CpuIoPeiExtra.uni   | Bin 1336 -> 667 bytes
 UefiCpuPkg/CpuMpPei/CpuMpPei.uni| Bin 1706 -> 852 bytes
 UefiCpuPkg/CpuMpPei/CpuMpPeiExtra.uni   | Bin 1344 -> 671 bytes
 .../Library/BaseUefiCpuLib/BaseUefiCpuLib.uni   | Bin 1826 -> 912 bytes
 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.uni| Bin 1962 -> 980 bytes
 .../BaseXApicX2ApicLib/BaseXApicX2ApicLib.uni   | Bin 2136 -> 1067 bytes
 .../DxeCpuExceptionHandlerLib.uni   | Bin 1810 -> 904 bytes
 .../SecPeiCpuExceptionHandlerLib.uni| Bin 1842 -> 920 bytes
 .../SmmCpuExceptionHandlerLib.uni   | Bin 1810 -> 904 bytes
 UefiCpuPkg/Library/MtrrLib/MtrrLib.uni  | Bin 1736 -> 867 bytes
 .../PlatformSecLibNull/PlatformSecLibNull.uni   | Bin 1644 -> 821 bytes
 .../SecPeiDxeTimerLibUefiCpu.uni| Bin 4168 -> 2083 bytes
 .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.uni | Bin 1672 -> 835 bytes
 .../SmmCpuPlatformHookLibNull.uni   | Bin 1604 -> 801 bytes
 .../PiSmmCommunication/PiSmmCommunicationPei.uni| Bin 2066 -> 1032 bytes
 .../PiSmmCommunicationPeiExtra.uni  | Bin 1370 -> 684 bytes
 .../PiSmmCommunication/PiSmmCommunicationSmm.uni| Bin 3004 -> 1501 bytes
 .../PiSmmCommunicationSmmExtra.uni  | Bin 1392 -> 695 bytes
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.uni| Bin 1868 -> 933 bytes
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmmExtra.uni   | Bin 1378 -> 688 bytes
 UefiCpuPkg/ResetVector/FixupVtf/ResetVector.uni | Bin 1696 -> 847 bytes
 .../ResetVector/FixupVtf/ResetVectorExtra.uni   | Bin 1310 -> 654 bytes
 UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.uni | Bin 1510 -> 754 bytes
 .../ResetVector/Vtf0/Bin/ResetVectorExtra.uni   | Bin 1310 -> 654 bytes
 UefiCpuPkg/ResetVector/Vtf0/ResetVector.uni | Bin 1454 -> 726 bytes
 UefiCpuPkg/ResetVector/Vtf0/ResetVectorExtra.uni| Bin 1310 -> 654 bytes
 UefiCpuPkg/SecCore/SecCore.uni  | Bin 2908 -> 1453 bytes
 UefiCpuPkg/SecCore/SecCoreExtra.uni | Bin 1316 -> 657 bytes
 UefiCpuPkg/UefiCpuPkg.uni   | Bin 21898 -> 10948 bytes
 UefiCpuPkg/UefiCpuPkgExtra.uni  | Bin 1346 -> 672 bytes
 .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.uni| Bin 2606 -> 1302 bytes
 .../Acpi/S3Resume2Pei/S3Resume2PeiExtra.uni | Bin 1354 -> 676 bytes
 39 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.uni b/UefiCpuPkg/CpuDxe/CpuDxe.uni index 
715766d..5ac7810 100644 Binary files a/UefiCpuPkg/CpuDxe/CpuDxe.uni and 
b/UefiCpuPkg/CpuDxe/CpuDxe.uni differ diff --git 
a/UefiCpuPkg/CpuDxe/CpuDxeExtra.uni b/UefiCpuPkg/CpuDxe/CpuDxeExtra.uni
index 0ba595e..fbfc2e1 100644
Binary files a/UefiCpuPkg/CpuDxe/CpuDxeExtra.uni and 
b/UefiCpuPkg/CpuDxe/CpuDxeExtra.uni differ diff --git 
a/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.uni b/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.uni
index 3ce8ec0..59456fb 100644
Binary files a/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.uni and 
b/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.uni differ diff --git 
a/UefiCpuPkg/CpuIo2Dxe/CpuIo2DxeExtra.uni 
b/UefiCpuPkg/CpuIo2Dxe/CpuIo2DxeExtra.uni
index 512a2f6..655da48 100644
Binary files a/UefiCpuPkg/CpuIo2Dxe/CpuIo2DxeExtra.uni and 
b/UefiCpuPkg/CpuIo2Dxe/CpuIo2DxeExtra.uni differ diff --git 
a/UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.uni b/UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.uni
index 89bac86..c3a212b 100644
Binary files a/UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.uni and 
b/UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.uni differ diff --git 
a/UefiCpuPkg/CpuIo2Smm/CpuIo2SmmExtra.uni 
b/UefiCpuPkg/CpuIo2Smm/CpuIo2SmmExtra.uni
index 84ba721..b1b82b0 100644
Binary files a/UefiCpuPkg/CpuIo2Smm/CpuIo2SmmExtra.uni and 
b/UefiCpuPkg/CpuIo2Smm/CpuIo2SmmExtra.

Re: [edk2] [Patch 2/6] UefiCpuPkg/CpuMpPei: Add GetApLoopMode() to get AP loop mode

[Fan, Jeff]

Mike,

I sent the patch to fix x64 version issue. Please help to review it.

Thanks!
Jeff

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fan, Jeff
Sent: Thursday, December 17, 2015 8:19 AM
To: Kinney, Michael D; edk2-devel@lists.01.org
Cc: Justen, Jordan L; Tian, Feng
Subject: Re: [edk2] [Patch 2/6] UefiCpuPkg/CpuMpPei: Add GetApLoopMode() to get 
AP loop mode

Mike,

I agree with your suggestion. I will update the patch.

I have received another request to add one PCD to specify the C-State value 
instead of the max C-State always. Thus, platform could decide the C-state by 
the balance the performance and power.

+  ## Specifies the AP target C-state for Mwait during POST phase.
+  #  The default value 0 means C1 state.
+  #  The value is defined as below.  # @Prompt The specified AP 
+ target C-state for Mwait.
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate|0|UINT8|0x0007

I will test 64bit PEI to find the root cause.

Thanks!
Jeff

-Original Message-
From: Kinney, Michael D
Sent: Thursday, December 17, 2015 7:07 AM
To: Fan, Jeff; edk2-devel@lists.01.org; Kinney, Michael D
Cc: Tian, Feng; Justen, Jordan L
Subject: RE: [Patch 2/6] UefiCpuPkg/CpuMpPei: Add GetApLoopMode() to get AP 
loop mode

Jeff,

I recommend a small change to GetApLoopMode().
1) Make sure PcdCpuApLoopMode is set to a valid value
2) Only check if CPU supports MONITOR/MWAIT if PcdCpuApLoopMode is set to 
ApInMwaitLoop.


Here is a proposal for the updated logic:
=
  ApLoopMode = PcdGet8 (PcdCpuApLoopMode);
  ASSERT (ApLoopMode >= ApInHltLoop && ApLoopMode <= ApInRunLoop);
  if (ApLoopMode == ApInMwaitLoop) {
AsmCpuid (CPUID_VERSION_INFO, NULL, NULL, , NULL);
if ((RegEcx & BIT3) == 0) {
  //
  // If processor does not support MONITOR/MWAIT feature
  // by CPUID.[EAX=01H]:ECX.BIT3, force AP in Hlt-loop mode
  //
  ApLoopMode = ApInHltLoop;
}
  }

I have tested this code on Quark/Galileo.  It works in HltLoop and RunLoop 
modes and correctly degrades MwaitLoop to HltLoop.

I have also tried this on OVMF (Qemu for Windows).  The 32-bit PEI works.  Does 
not support MONITOR/MWAIT.  However, when I tried 64-bit PEI, it only detects 1 
CPU and crashes QEMU shortly there after.  I am concerned that the 64-bit AP 
detect code has an issue.

Best regards,

Mike

> -Original Message-----
> From: Fan, Jeff
> Sent: Sunday, December 13, 2015 6:27 PM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng <feng.t...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; Justen, Jordan L 
> <jordan.l.jus...@intel.com>
> Subject: [Patch 2/6] UefiCpuPkg/CpuMpPei: Add GetApLoopMode() to get 
> AP loop mode
> 
> Add GetApLoopMode() that will get PCD PcdCpuApLoopMode firstly.
> If it is
> ApInMwaitLoop, we will check if MONITOR/MWAIT feature supported by 
> CPUID. If MONITOR/MWAIT feature is not supported, force AP loop mode 
> to ApInHltLoop.
> 
> GetApLoopMode() also return the maximum C-state supported by processor 
> and the largest line size required.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> ---
>  UefiCpuPkg/CpuMpPei/CpuMpPei.c  | 61
> +
>  UefiCpuPkg/CpuMpPei/CpuMpPei.h  |  6 
>  UefiCpuPkg/CpuMpPei/CpuMpPei.inf|  1 +
>  UefiCpuPkg/Include/Register/Cpuid.h |  2 ++
>  4 files changed, 70 insertions(+)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c 
> b/UefiCpuPkg/CpuMpPei/CpuMpPei.c index 2e6e761..653e22c 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> @@ -118,6 +118,67 @@ ApFuncEnableX2Apic (  }
> 
>  /**
> +  Get AP loop mode.
> +
> +  @param MaxCState  Returns the maximum C-state
> supported by processor.
> +  @param MonitorFilterSize  Returns the largest monitor-line
> size in bytes.
> +
> +  @return The AP loop mode.
> +**/
> +UINT8
> +GetApLoopMode (
> +  OUT UINT8  *MaxCState,
> +  OUT UINT16 *MonitorFilterSize
> +  )
> +{
> +  UINT8  ApLoopMode;
> +  UINT32 RegEbx;
> +  UINT32 RegEcx;
> +  UINT32 RegEdx;
> +  UINT8  Index;
> +  UINT32 Params;
> +
> +  ASSERT (MaxCState != NULL);
> +  ASSERT (MonitorFilterSize != NULL);
> +
> +  ApLoopMode = PcdGet8 (PcdCpuApLoopMode);  AsmCpuid 
> + (CPUID_VERSION_INFO, NULL, NULL, , NULL);  if ((RegEcx &
> + BIT3) == 0) {
> +//
> +// If processor does not support MONITOR/MWAIT f

Re: [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get installed above 4GB

[Fan, Jeff]

I agree with 2). New function is better.

Jeff
-Original Message-
From: Yao, Jiewen 
Sent: Wednesday, December 16, 2015 8:49 AM
To: Samer El-Haj-Mahmoud; edk2-devel@lists.01.org
Cc: Samer El-Haj-Mahmoud; Fan, Jeff
Subject: RE: [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get 
installed above 4GB

HI Samer
This mechanism is good. I like it because it brings new capability and keeps 
old compatibility at same time.

I have 2 suggestion for your consideration:
1) I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.

2) Can we create a new function to allocate <4G at first, if fail, allocate any 
memory?
Then we can update all caller to consume this new function.
We can avoid adding ERROR check anywhere. I also suggest we need add some debug 
message there, we can add into one place.

Thank you
Yao Jiewen

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Samer 
El-Haj-Mahmoud
Sent: Wednesday, December 16, 2015 4:40 AM
To: edk2-devel@lists.01.org
Cc: Samer El-Haj-Mahmoud; Fan, Jeff
Subject: [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get 
installed above 4GB

Some ARM systems do not have available memory below 4GB, and still support 
ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
below 4GB fails.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud <el...@hpe.com>
---
 .../AcpiSupportAcpiSupportProtocol.c   | 69 --
 1 file changed, 65 insertions(+), 4 deletions(-)

diff --git 
a/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportAcpiSupportProtocol.c
 
b/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportAcpiSupportProtocol.c
index 6443c3a..72a7fe1 100644
--- 
a/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportAcpiSupportProtocol.c
+++ b/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportA
+++ cpiSupportProtocol.c
@@ -2,6 +2,7 @@
   ACPI Support Protocol implementation
 
 Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions @@ -533,6 +534,14 @@ ReallocateAcpiTableBuffer (
   );
 
   if (EFI_ERROR (Status)) {
+Status = gBS->AllocatePages (
+AllocateAnyPages,
+EfiACPIReclaimMemory,
+EFI_SIZE_TO_PAGES (TotalSize),
+
+);
+  }
+  if (EFI_ERROR (Status)) {
 return EFI_OUT_OF_RESOURCES;
   }
 
@@ -548,8 +557,13 @@ ReallocateAcpiTableBuffer (
   //
   // Update RSDP to point to the new Rsdt and Xsdt address.
   //
-  AcpiSupportInstance->Rsdp1->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt1;
-  AcpiSupportInstance->Rsdp3->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt3;
+  if ((UINTN) AcpiSupportInstance->Rsdt3 < BASE_4GB) {
+AcpiSupportInstance->Rsdp1->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt1;
+AcpiSupportInstance->Rsdp3->RsdtAddress = (UINT32) (UINTN) 
+ AcpiSupportInstance->Rsdt3;  } else {
+AcpiSupportInstance->Rsdp1->RsdtAddress = 0;
+AcpiSupportInstance->Rsdp3->RsdtAddress = 0;  }
   CurrentData = (UINT64) (UINTN) AcpiSupportInstance->Xsdt;
   CopyMem (>Rsdp3->XsdtAddress, , sizeof 
(UINT64));
 
@@ -669,6 +683,15 @@ AddTableToList (
 CurrentTableList->NumberOfPages,
 >PageAddress
 );
+
+if (EFI_ERROR (Status)) {
+  Status = gBS->AllocatePages (
+  AllocateAnyPages,
+  EfiACPIMemoryNVS,
+  CurrentTableList->NumberOfPages,
+  >PageAddress
+  );
+}
   } else {
 //
 // All other tables are ACPI reclaim memory, no alignment requirements.
@@ -679,6 +702,15 @@ AddTableToList (
 CurrentTableList->NumberOfPages,
 >PageAddress
 );
+
+if (EFI_ERROR (Status)) {
+  Status = gBS->AllocatePages (
+  AllocateAnyPages,
+  EfiACPIReclaimMemory,
+  CurrentTableList->NumberOfPages,
+  >PageAddress
+  );
+}
   }
   //
   // Check return value from memory alloc.
@@ -1785,6 +1817,15 @@ AcpiSupportAcpiSupportConstructor (
   );
 
   if (EFI_ERROR (Status)) {
+Status = gBS->AllocatePages (
+AllocateAnyPages,
+EfiACPIReclaimMemory,
+EFI_SIZE_TO_PAGES (RsdpTableSize),
+
+);
+  }
+
+  if (EFI_ERROR (

Re: [edk2] [PATCH v2 08/20] IntelFrameworkModulePkg: Convert all .uni files to utf-8

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Justen, Jordan L 
Sent: Saturday, December 05, 2015 4:13 AM
To: edk2-devel@lists.01.org
Cc: Justen, Jordan L; Fan, Jeff
Subject: [PATCH v2 08/20] IntelFrameworkModulePkg: Convert all .uni files to 
utf-8

To convert these files I ran:

$ python3 BaseTools/Scripts/ConvertUni.py IntelFrameworkModulePkg

Cc: Jeff Fan <jeff@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 .../Bus/Isa/IsaBusDxe/IsaBusDxe.uni | Bin 2658 -> 1328 bytes
 .../Bus/Isa/IsaBusDxe/IsaBusDxeExtra.uni| Bin 1336 -> 667 bytes
 .../Bus/Isa/IsaFloppyDxe/IsaFloppyDxe.uni   | Bin 2444 -> 1221 bytes
 .../Bus/Isa/IsaFloppyDxe/IsaFloppyDxeExtra.uni  | Bin 1348 -> 673 bytes
 .../Bus/Isa/IsaFloppyPei/IsaFloppyPei.uni   | Bin 2348 -> 1173 bytes
 .../Bus/Isa/IsaFloppyPei/IsaFloppyPeiExtra.uni  | Bin 1358 -> 678 bytes
 .../Bus/Isa/IsaIoDxe/IsaIoDxe.uni   | Bin 2414 -> 1206 bytes
 .../Bus/Isa/IsaIoDxe/IsaIoDxeExtra.uni  | Bin 1334 -> 666 bytes
 .../Bus/Isa/IsaSerialDxe/IsaSerialDxe.uni   | Bin 2094 -> 1046 bytes
 .../Bus/Isa/IsaSerialDxe/IsaSerialDxeExtra.uni  | Bin 1366 -> 682 bytes
 .../Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.uni   | Bin 1928 -> 963 bytes
 .../Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxeExtra.uni  | Bin 1358 -> 678 bytes
 .../Ps2MouseAbsolutePointerDxe.uni  | Bin 2064 -> 1031 bytes
 .../Ps2MouseAbsolutePointerDxeExtra.uni | Bin 1394 -> 696 bytes
 .../Bus/Isa/Ps2MouseDxe/Ps2MouseDxe.uni | Bin 1628 -> 813 bytes
 .../Bus/Isa/Ps2MouseDxe/Ps2MouseDxeExtra.uni| Bin 1346 -> 672 bytes
 .../Bus/Pci/IdeBusDxe/IdeBusDxe.uni | Bin 1764 -> 881 bytes
 .../Bus/Pci/IdeBusDxe/IdeBusDxeExtra.uni| Bin 1328 -> 663 bytes
 .../Bus/Pci/VgaMiniPortDxe/VgaMiniPort.uni  | Bin 2038 -> 1018 bytes
 .../Bus/Pci/VgaMiniPortDxe/VgaMiniPortExtra.uni | Bin 1352 -> 675 bytes
 .../Csm/BiosThunk/BlockIoDxe/BlockIoDxe.uni | Bin 2138 -> 1068 bytes
 .../Csm/BiosThunk/BlockIoDxe/BlockIoDxeExtra.uni| Bin 1366 -> 682 bytes
 .../Csm/BiosThunk/KeyboardDxe/KeyboardDxe.uni   | Bin 2044 -> 1021 bytes
 .../Csm/BiosThunk/KeyboardDxe/KeyboardDxeExtra.uni  | Bin 1366 -> 682 bytes
 .../Csm/BiosThunk/Snp16Dxe/BiosSnp16.uni| Bin 1824 -> 911 bytes
 .../Csm/BiosThunk/Snp16Dxe/BiosSnp16Extra.uni   | Bin 1392 -> 695 bytes
 .../Csm/BiosThunk/VideoDxe/BiosVideoDxe.uni | Bin 1984 -> 991 bytes
 .../Csm/BiosThunk/VideoDxe/BiosVideoDxeExtra.uni| Bin 1362 -> 680 bytes
 .../Csm/LegacyBiosDxe/LegacyBiosDxe.uni | Bin 1848 -> 923 bytes
 .../Csm/LegacyBiosDxe/LegacyBiosDxeExtra.uni| Bin 1378 -> 688 bytes
 IntelFrameworkModulePkg/IntelFrameworkModulePkg.uni | Bin 37484 -> 18741 bytes
 .../IntelFrameworkModulePkgExtra.uni| Bin 1398 -> 698 bytes
 .../BaseUefiTianoDecompressLib.uni  | Bin 2040 -> 1019 bytes
 .../Library/DxeCapsuleLib/DxeCapsuleLib.uni | Bin 1840 -> 919 bytes
 .../DxeReportStatusCodeLib.uni  | Bin 1986 -> 992 bytes
 .../Library/GenericBdsLib/GenericBdsLib.uni | Bin 2378 -> 1188 bytes
 .../Library/GenericBdsLib/GenericBdsStrings.uni | Bin 3852 -> 1926 bytes
 .../LegacyBootMaintUiLib/LegacyBootMaintUiLib.uni   | Bin 1800 -> 899 bytes
 .../LegacyBootMaintUiStrings.uni| Bin 6380 -> 3190 bytes
 .../LegacyBootManagerLib/LegacyBootManagerLib.uni   | Bin 1736 -> 867 bytes
 .../LzmaArchDecompressLib.uni   | Bin 2480 -> 1239 bytes
 .../LzmaCustomDecompressLib/LzmaDecompressLib.uni   | Bin 2274 -> 1136 bytes
 .../PeiDxeDebugLibReportStatusCode.uni  | Bin 1896 -> 947 bytes
 .../Library/PeiRecoveryLib/PeiRecoveryLib.uni   | Bin 2272 -> 1135 bytes
 .../Library/PeiS3Lib/PeiS3Lib.uni   | Bin 2392 -> 1195 bytes
 .../Library/PlatformBdsLibNull/PlatformBdsLib.uni   | Bin 1880 -> 939 bytes
 .../SmmRuntimeDxeReportStatusCodeLibFramework.uni   | Bin 2844 -> 1421 bytes
 .../Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.uni  | Bin 1916 -> 957 bytes
 .../Acpi/AcpiS3SaveDxe/AcpiS3SaveDxeExtra.uni   | Bin 1368 -> 683 bytes
 .../Acpi/AcpiSupportDxe/AcpiSupportDxe.uni  | Bin 2246 -> 1122 bytes
 .../Acpi/AcpiSupportDxe/AcpiSupportDxeExtra.uni | Bin 1366 -> 682 bytes
 IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.uni | Bin 5172 -> 2585 bytes
 .../Universal/BdsDxe/BdsDxeExtra.uni| Bin 1370 -> 684 bytes
 .../Universal/BdsDxe/BootMaint/Bmstring.uni | Bin 38776 -> 19388 bytes
 .../BdsDxe/BootMngr/BootManagerStrings.uni  | Bin 3344 -> 1680 bytes
 .../Bd

Re: [edk2] [Patch] MdeModulePkg: Fix GraphicsConsole driver resolution out of sync issue

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Ni, Ruiyu 
Sent: Friday, January 08, 2016 3:14 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Fan, Jeff
Subject: [Patch] MdeModulePkg: Fix GraphicsConsole driver resolution out of 
sync issue

When the GOP doesn't support the resolution specified by 
PcdVideoHorizontalResolution and PcdVideoVerticalResolution, the code tries to 
set the resolution to 800x600 but uses the resolution equals to the PCD when 
calculating the text print position.
The patch fixes the bug by updating the resolution to 800x600 for this case.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
---
 .../Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c| 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git 
a/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c 
b/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c
index 74218c8..7b1c37b 100644
--- a/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c
+++ b/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.
+++ c
@@ -1,7 +1,7 @@
 /** @file
   This is the main routine for initializing the Graphics Console support 
routines.
 
-Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -480,10 +480,12 
@@ GraphicsConsoleControllerDriverStart (
 //
 // if not supporting current mode, try 800x600 which is required by 
UEFI/EFI spec
 //
+HorizontalResolution = 800;
+VerticalResolution   = 600;
 Status = CheckModeSupported (
  Private->GraphicsOutput,
- 800,
- 600,
+ HorizontalResolution,
+ VerticalResolution,
  
  );
 Mode = Private->GraphicsOutput->Mode;
--
2.6.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Registering custom exception/interrupt handler function.

[Fan, Jeff]

1. The exception message maybe printed by DebugLib. Release/Production image 
use NULL DebugLib instance. It may make sense without output on serial port.
2. "Already started" makes sense due to CPU driver has already registered its 
own exception handler.

Your order to unregister with NULL pointer and to register your own exception 
handler is correct. 

I guessed the following happened.
Unregister is successfully, CPU driver unregister its own exception handler and 
restore the original IDT entry (setup in DXE Core before CPU driver dispatched, 
its exception handler provided by CpuExceptionHanderLib to dump exception 
message from serial port).
But register your own exception handler is not successful, so the GP is handled 
by original IDT entry to dump the exception message from serial port.

It seems that there is one bug in Cpu Dxe driver RegisterInterruptHandler () 
implementation.

Jeff
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Sergey 
Tretiyak
Sent: Tuesday, December 29, 2015 4:28 PM
To: Fan, Jeff
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Registering custom exception/interrupt handler function.

1. I actually don't get any prints when I do that

2. I get "Already started" error from the RegisterInterruptHandler when I try 
to register my own handler, and again I don't get any prints.

On Tue, Dec 29, 2015 at 3:04 AM, Fan, Jeff <jeff@intel.com> wrote:

> Got you.
>
>
>
> Could you try the following tests on your system?
>
>
>
> 1.   Not to unregister exception handler with NULL pointer and not to
> register your own exception handler and just to generate one GP fault.
> What’s exception message dumped?
>
> 2.   Not to unregister exception handler with NULL pointer and just
> to register your own exception handler? Then what happened?
>
>
>
> For your case, actually you needn’t to link any library, instead you 
> should consume CPU ARCH protocol only.
>
>
>
> Jeff
>
>
>
> *From:* Sergey Tretiyak [mailto:sergey.treti...@gmail.com]
> *Sent:* Monday, December 28, 2015 7:58 PM
>
> *To:* Fan, Jeff
> *Cc:* edk2-devel@lists.01.org
> *Subject:* Re: [edk2] Registering custom exception/interrupt handler 
> function.
>
>
>
> Yes, here's what I get printed:
>
>  X64 Exception Type - 000D CPU Apic ID -  
>
> RIP  - 39F37134, CS  - 0038, RFLAGS - 
> 00010206
>
> ExceptionData - 
>
> RAX  - 0014, RCX - 5DF75000, RDX - 
> 
>
> RBX  - 8013, RSP - 46AD15E0, RBP - 
> 46AD16B0
>
> RSI  - 0001, RDI - 5DF75000
>
> R8   - , R9  - , R10 - 46AD1200
>
> R11  - 0002, R12 - 3A871518, R13 - 
> 
>
> R14  - , R15 - 3A771998
>
> DS   - 0018, ES  - 0018, FS  - 0018
>
> GS   - 0018, SS  - 0018
>
> CR0  - 8013, CR2 - , CR3 - 
> 468B
>
> CR4  - 2668, CR8 - 
>
> DR0  - , DR1 - , DR2 - 
> 
>
> DR3  - , DR6 - FFFE0FF0, DR7 - 
> 0400
>
> GDTR - 44DEABE0 0047, LDTR - 
>
> IDTR - 000044DEC4A0 0FFF,   TR - 
>
> FXSAVE_STATE - 46AD1240
>
>  Find PE image (path to pdb file...) 
> (ImageBase=39F36000,
> EntryPoint=39F362C0) 
>
>
>
> On Mon, Dec 28, 2015 at 9:56 AM, Fan, Jeff <jeff@intel.com> wrote:
>
> Sorry. I missed this mail last week.
>
>
>
> Are you sure the exception message included the following message?
>
> " (ImageBase=%016lx, EntryPoint=%016lx) \n",
>
>
>
> Or could you post the whole exception message not only the first line?
>
>
>
> Jeff
>
>
>
> *From:* Sergey Tretiyak [mailto:sergey.treti...@gmail.com]
> *Sent:* Monday, December 21, 2015 8:06 PM
> *To:* Fan, Jeff
> *Cc:* edk2-devel@lists.01.org
> *Subject:* Re: [edk2] Registering custom exception/interrupt handler 
> function.
>
>
>
> It is used, I get the message printed from DumpCpuContent() in 
> ArchExceptionHandler.c, that starts with " X64 Exception Type - ...
> CPU Apic ID - ... ...".
>
>
>
> On Mon, Dec 21, 2015 at 5:09 AM, Fan, Jeff <jeff@intel.com> wrote:
>
> Could you post the exception message from serial port? Then we could 
> know if UefiCpuPkg/Library/CpuExceptionHandlerLib i

Re: [edk2] Registering custom exception/interrupt handler function.

[Fan, Jeff]

Could you post the exception message from serial port? Then we could know if 
UefiCpuPkg/Library/CpuExceptionHandlerLib is used or not?

Jeff

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Sergey 
Tretiyak
Sent: Sunday, December 20, 2015 6:05 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Registering custom exception/interrupt handler function.

Hi to all.
I'm trying to write some EDK shell app for the latest Intel Skylake CPU, and I 
need to use a custom GP exception handler during its work.
I'm trying to locate the EFI_CPU_ARCH_PROTOCOL by using 
gEfiCpuArchProtocolGuid, then I'm using the RegisterInterruptHandler protocol 
function (first with NULL to unregister the existing handler, and then with 
pointer to my handler function), and it returns me EFI_SUCCESS in both calls. 
But when I actually get a GP, it doesn't reach my custom handler function, and 
probably continues to use some kind of default exception handler that prints a 
default exception message on my serial port.
What I am doing wrong? Perhaps I'm compiling my app with a wrong library?
Which library should be used for EFI_CPU_ARCH_PROTOCOL to work correctly as 
expected?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Correct CPUID leaf used to detect SMM mode

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Kinney, Michael D 
Sent: Wednesday, December 23, 2015 7:51 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff
Subject: [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Correct CPUID leaf used to detect 
SMM mode

Use Bit 29 of CPUID leaf CPUID_EXTENDED_CPU_SIG (0x8001) to determine the 
SMM save state mode.  The previous version of this code used CPUID leaf 
CPUID_VERSION_INFO (0x0001).

Cc: Jeff Fan <jeff@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
index fb46551..949dd4e 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -913,13 +913,18 @@ PiCpuSmmEntry (
   //
   // Retrieve CPU Family
   //
-  AsmCpuid (CPUID_VERSION_INFO, , NULL, NULL, );
+  AsmCpuid (CPUID_VERSION_INFO, , NULL, NULL, NULL);
   FamilyId = (RegEax >> 8) & 0xf;
   ModelId = (RegEax >> 4) & 0xf;
   if (FamilyId == 0x06 || FamilyId == 0x0f) {
 ModelId = ModelId | ((RegEax >> 12) & 0xf0);
   }
 
+  RegEdx = 0;
+  AsmCpuid (CPUID_EXTENDED_FUNCTION, , NULL, NULL, NULL);  if 
+ (RegEax >= CPUID_EXTENDED_CPU_SIG) {
+AsmCpuid (CPUID_EXTENDED_CPU_SIG, NULL, NULL, NULL, );  }
   //
   // Determine the mode of the CPU at the time an SMI occurs
   //   Intel(R) 64 and IA-32 Architectures Software Developer's Manual
--
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Fix failure when PcdCpuSmmDebug is TRUE

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Kinney, Michael D 
Sent: Wednesday, December 23, 2015 7:51 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff
Subject: [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Fix failure when PcdCpuSmmDebug is 
TRUE

If PcdCpuSmmDebug is set to TRUE, then the first time the function 
CpuSmmDebugEntry () is called during the first normal SMI, the registers DR6 or 
DR7 may be set to invalid values due to gSmst not being fully initialized yet.  
Instead, use gSmmCpuPrivate that is fully initialized for the first SMI to look 
up CpuSaveState for the currently executing CPU.

Cc: Jeff Fan <jeff@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index 620b013..79b7c90 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -943,7 +943,7 @@ SmmStartupThisAp (
 }
 
 /**
-  This funciton sets DR6 & DR7 according to SMM save state, before running SMM 
C code.
+  This function sets DR6 & DR7 according to SMM save state, before running SMM 
C code.
   They are useful when you want to enable hardware breakpoints in SMM without 
entry SMM mode.
 
   NOTE: It might not be appreciated in runtime since it might @@ -961,7 +961,7 
@@ CpuSmmDebugEntry (
   SMRAM_SAVE_STATE_MAP *CpuSaveState;
   
   if (FeaturePcdGet (PcdCpuSmmDebug)) {
-CpuSaveState = (SMRAM_SAVE_STATE_MAP *)gSmst->CpuSaveState[CpuIndex];
+CpuSaveState = (SMRAM_SAVE_STATE_MAP 
+ *)gSmmCpuPrivate->CpuSaveState[CpuIndex];
 if (mSmmSaveStateRegisterLma == EFI_SMM_SAVE_STATE_REGISTER_LMA_32BIT) {
   AsmWriteDr6 (CpuSaveState->x86._DR6);
   AsmWriteDr7 (CpuSaveState->x86._DR7); @@ -973,7 +973,7 @@ 
CpuSmmDebugEntry (  }
 
 /**
-  This funciton restores DR6 & DR7 to SMM save state.
+  This function restores DR6 & DR7 to SMM save state.
 
   NOTE: It might not be appreciated in runtime since it might
 conflict with OS debugging facilities. Turn them off in RELEASE.
@@ -990,7 +990,7 @@ CpuSmmDebugExit (
   SMRAM_SAVE_STATE_MAP *CpuSaveState;
 
   if (FeaturePcdGet (PcdCpuSmmDebug)) {
-CpuSaveState = (SMRAM_SAVE_STATE_MAP *)gSmst->CpuSaveState[CpuIndex];
+CpuSaveState = (SMRAM_SAVE_STATE_MAP 
+ *)gSmmCpuPrivate->CpuSaveState[CpuIndex];
 if (mSmmSaveStateRegisterLma == EFI_SMM_SAVE_STATE_REGISTER_LMA_32BIT) {
   CpuSaveState->x86._DR7 = (UINT32)AsmReadDr7 ();
   CpuSaveState->x86._DR6 = (UINT32)AsmReadDr6 ();
--
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Registering custom exception/interrupt handler function.

[Fan, Jeff]

Sorry. I missed this mail last week.

Are you sure the exception message included the following message?
" (ImageBase=%016lx, EntryPoint=%016lx) \n",

Or could you post the whole exception message not only the first line?

Jeff

From: Sergey Tretiyak [mailto:sergey.treti...@gmail.com]
Sent: Monday, December 21, 2015 8:06 PM
To: Fan, Jeff
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Registering custom exception/interrupt handler function.

It is used, I get the message printed from DumpCpuContent() in 
ArchExceptionHandler.c, that starts with " X64 Exception Type - ... CPU 
Apic ID - ... ...".

On Mon, Dec 21, 2015 at 5:09 AM, Fan, Jeff 
<jeff@intel.com<mailto:jeff@intel.com>> wrote:
Could you post the exception message from serial port? Then we could know if 
UefiCpuPkg/Library/CpuExceptionHandlerLib is used or not?

Jeff

-Original Message-
From: edk2-devel 
[mailto:edk2-devel-boun...@lists.01.org<mailto:edk2-devel-boun...@lists.01.org>]
 On Behalf Of Sergey Tretiyak
Sent: Sunday, December 20, 2015 6:05 PM
To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Subject: [edk2] Registering custom exception/interrupt handler function.

Hi to all.
I'm trying to write some EDK shell app for the latest Intel Skylake CPU, and I 
need to use a custom GP exception handler during its work.
I'm trying to locate the EFI_CPU_ARCH_PROTOCOL by using 
gEfiCpuArchProtocolGuid, then I'm using the RegisterInterruptHandler protocol 
function (first with NULL to unregister the existing handler, and then with 
pointer to my handler function), and it returns me EFI_SUCCESS in both calls. 
But when I actually get a GP, it doesn't reach my custom handler function, and 
probably continues to use some kind of default exception handler that prints a 
default exception message on my serial port.
What I am doing wrong? Perhaps I'm compiling my app with a wrong library?
Which library should be used for EFI_CPU_ARCH_PROTOCOL to work correctly as 
expected?
___
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Registering custom exception/interrupt handler function.

[Fan, Jeff]

Got you.

Could you try the following tests on your system?


1.   Not to unregister exception handler with NULL pointer and not to 
register your own exception handler and just to generate one GP fault. What’s 
exception message dumped?

2.   Not to unregister exception handler with NULL pointer and just to 
register your own exception handler? Then what happened?


For your case, actually you needn’t to link any library, instead you should 
consume CPU ARCH protocol only.

Jeff

From: Sergey Tretiyak [mailto:sergey.treti...@gmail.com]
Sent: Monday, December 28, 2015 7:58 PM
To: Fan, Jeff
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Registering custom exception/interrupt handler function.

Yes, here's what I get printed:
 X64 Exception Type - 000D CPU Apic ID -  
RIP  - 39F37134, CS  - 0038, RFLAGS - 00010206
ExceptionData - 
RAX  - 0014, RCX - 5DF75000, RDX - 
RBX  - 8013, RSP - 46AD15E0, RBP - 46AD16B0
RSI  - 0001, RDI - 5DF75000
R8   - , R9  - , R10 - 46AD1200
R11  - 0002, R12 - 3A871518, R13 - 
R14  - , R15 - 3A771998
DS   - 0018, ES  - 0018, FS  - 0018
GS   - 0018, SS  - 0018
CR0  - 8013, CR2 - , CR3 - 468B
CR4  - 2668, CR8 - 
DR0  - , DR1 - , DR2 - 
DR3  - , DR6 - FFFE0FF0, DR7 - 0400
GDTR - 44DEABE0 0047, LDTR - 
IDTR - 44DEC4A0 0FFF,   TR - 
FXSAVE_STATE - 46AD1240
 Find PE image (path to pdb file...) (ImageBase=39F36000, 
EntryPoint=39F362C0) 

On Mon, Dec 28, 2015 at 9:56 AM, Fan, Jeff 
<jeff@intel.com<mailto:jeff@intel.com>> wrote:
Sorry. I missed this mail last week.

Are you sure the exception message included the following message?
" (ImageBase=%016lx, EntryPoint=%016lx) \n",

Or could you post the whole exception message not only the first line?

Jeff

From: Sergey Tretiyak 
[mailto:sergey.treti...@gmail.com<mailto:sergey.treti...@gmail.com>]
Sent: Monday, December 21, 2015 8:06 PM
To: Fan, Jeff
Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Subject: Re: [edk2] Registering custom exception/interrupt handler function.

It is used, I get the message printed from DumpCpuContent() in 
ArchExceptionHandler.c, that starts with " X64 Exception Type - ... CPU 
Apic ID - ... ...".

On Mon, Dec 21, 2015 at 5:09 AM, Fan, Jeff 
<jeff@intel.com<mailto:jeff@intel.com>> wrote:
Could you post the exception message from serial port? Then we could know if 
UefiCpuPkg/Library/CpuExceptionHandlerLib is used or not?

Jeff

-Original Message-
From: edk2-devel 
[mailto:edk2-devel-boun...@lists.01.org<mailto:edk2-devel-boun...@lists.01.org>]
 On Behalf Of Sergey Tretiyak
Sent: Sunday, December 20, 2015 6:05 PM
To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Subject: [edk2] Registering custom exception/interrupt handler function.

Hi to all.
I'm trying to write some EDK shell app for the latest Intel Skylake CPU, and I 
need to use a custom GP exception handler during its work.
I'm trying to locate the EFI_CPU_ARCH_PROTOCOL by using 
gEfiCpuArchProtocolGuid, then I'm using the RegisterInterruptHandler protocol 
function (first with NULL to unregister the existing handler, and then with 
pointer to my handler function), and it returns me EFI_SUCCESS in both calls. 
But when I actually get a GP, it doesn't reach my custom handler function, and 
probably continues to use some kind of default exception handler that prints a 
default exception message on my serial port.
What I am doing wrong? Perhaps I'm compiling my app with a wrong library?
Which library should be used for EFI_CPU_ARCH_PROTOCOL to work correctly as 
expected?
___
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 8/8] IntelFrameworkModulePkg: Remove the undefined PCD help and prompt strings

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Wednesday, December 23, 2015 5:57 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 8/8] IntelFrameworkModulePkg: Remove the undefined PCD 
help and prompt strings

IntelFrameworkModulePkg.uni includes some undefined PCD help and prompt 
strings, which will be removed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming@intel.com>
---
 .../IntelFrameworkModulePkg.uni| 26 +-
 1 file changed, 1 insertion(+), 25 deletions(-)

diff --git a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.uni 
b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.uni
index 019edf7..8528f5d 100644
--- a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.uni
+++ b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.uni
@@ -10,7 +10,7 @@
 // are licensed and made available under the terms and conditions of the BSD 
License  // which accompanies this distribution. The full text of the license 
may be found at  // http://opensource.org/licenses/bsd-license.php
-// 
+//
 // THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,  // 
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 //
@@ -102,22 +102,6 @@

 "TRUE  - Use the optimized timing for best PS2 detection 
performance.\n"

 "FALSE - Use the normal timing to detect PS2."
 
-#string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdSetupVideoHorizontalResolution_PROMPT
  #language en-US "Video Horizontal Resolution of Text Setup"
-
-#string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdSetupVideoHorizontalResolution_HELP
  #language en-US "Specify the video horizontal resolution of text setup."
-
-#string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdSetupVideoVerticalResolution_PROMPT
  #language en-US "Video Vertical Resolution of Text Setup"
-
-#string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdSetupVideoVerticalResolution_HELP
  #language en-US "Specify the video vertical resolution of text setup."
-
-#string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdSetupConOutColumn_PROMPT  
#language en-US "Console Output Column of Text Setup"
-
-#string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdSetupConOutColumn_HELP  
#language en-US "Specify the console output column of text setup."
-
-#string STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdSetupConOutRow_PROMPT 
 #language en-US "Console Output Row of Text Setup"
-
-#string STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdSetupConOutRow_HELP  
#language en-US "Specify the console output row of text setup."
-
 #string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdStatusCodeUseOEM_PROMPT  
#language en-US "Report StatusCode via OEM Device"
 
 #string STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdStatusCodeUseOEM_HELP 
 #language en-US "Indicates if OEM device is enabled as StatusCode report 
device. It is only used in Framework StatusCode implementation. \n"
@@ -172,14 +156,6 @@

  "TRUE  - The complete boot cycle has not happened before.\n"

  "FALSE - The complete boot cycle has happened before."
 
-#string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdPlatformBootTimeOut_PROMPT  
#language en-US "Boot Timeout (s)"
-
-#string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdPlatformBootTimeOut_HELP  
#language en-US "The number of seconds that the firmware will wait before 
initiating the original default boot selection. A value of 0 indicates that the 
default boot selection is to be initiated immediately on boot. The value of 
0x then firmware will wait for user input before booting."
-
-#string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdHardwareErrorRecordLevel_PROMPT
  #language en-US "Error Level For Hardware Recorder"
-
-#string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdHardwareErrorRecordLevel_HELP  
#language en-US "Error level for hardware recorder. If value 0, platform does 
not support feature of hardware error record."
-
 #string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdOpromReservedMemoryBase_PROMPT 
 #language en-US "Reserved Memory Base Address for OPROM"
 
 #string 
STR_gEfiIntelFrameworkModulePkgTokenSpaceGuid_PcdOpromReservedMemoryBase_HELP  
#language en-US "Specify m

Re: [edk2] [Patch 6/8] UefiCpuPkg: Add the missing module uni for CpuS3DataDxe

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Wednesday, December 23, 2015 5:57 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 6/8] UefiCpuPkg: Add the missing module uni for 
CpuS3DataDxe

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming@intel.com>
---
 UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf  |  4 +++
 UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.uni  | 40 +++
 UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxeExtra.uni | 20 ++
 3 files changed, 64 insertions(+)
 create mode 100644 UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.uni
 create mode 100644 UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxeExtra.uni

diff --git a/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf 
b/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
index 9143b87..857e12b 100644
--- a/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
+++ b/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -25,6 +25,7 @@
 [Defines]
   INF_VERSION= 0x00010005
   BASE_NAME  = CpuS3DataDxe
+  MODULE_UNI_FILE= CpuS3DataDxe.uni
   FILE_GUID  = 4D2E57EE-0E3F-44DD-93C4-D3B57E96945D
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
@@ -62,3 +63,6 @@
 
 [Depex]
   gEfiMpServiceProtocolGuid
+
+[UserExtensions.TianoCore."ExtraFiles"]
+  CpuS3DataDxeExtra.uni
diff --git a/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.uni 
b/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.uni
new file mode 100644
index 000..4a0218f
--- /dev/null
+++ b/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.uni
@@ -0,0 +1,40 @@
+// /** @file
+// ACPI CPU Data initialization module
+//
+// This module initializes the ACPI_CPU_DATA structure and registers 
+the address // of this structure in the PcdCpuS3DataAddress PCD.  This 
+is a generic/simple // version of this module.  It does not provide a 
+machine check handler or CPU // register initialization tables for ACPI 
+S3 resume.  It also only supports the // number of CPUs reported by the 
+MP Services Protocol, so this module does not // support hot plug CPUs.  
+This module can be copied into a CPU specific package // and customized if 
these additional features are required.
+//
+// Copyright (c) 2015, Intel Corporation. All rights reserved. // 
+// Copyright (c) 2015, Red Hat, Inc.
+//
+// This program and the accompanying materials // are licensed and made 
+available under the terms and conditions of the BSD License // which 
+accompanies this distribution.  The full text of the license may be 
+found at // http://opensource.org/licenses/bsd-license.php
+//
+// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" 
+BASIS, // WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+//
+// **/
+
+#string STR_MODULE_ABSTRACT
+#language en-US
+"ACPI CPU Data initialization module"
+
+#string STR_MODULE_DESCRIPTION
+#language en-US
+"This module initializes the ACPI_CPU_DATA structure and registers the address 
"
+"of this structure in the PcdCpuS3DataAddress PCD.  This is a generic/simple "
+"version of this module.  It does not provide a machine check handler or CPU "
+"register initialization tables for ACPI S3 resume.  It also only supports the 
"
+"number of CPUs reported by the MP Services Protocol, so this module does not "
+"support hot plug CPUs.  This module can be copied into a CPU specific package 
"
+"and customized if these additional features are required."
+
+
diff --git a/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxeExtra.uni 
b/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxeExtra.uni
new file mode 100644
index 000..050f25f
--- /dev/null
+++ b/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxeExtra.uni
@@ -0,0 +1,20 @@
+// /** @file
+// CpuS3DataDxe Localized Strings and Content // // Copyright (c) 2015, 
+Intel Corporation. All rights reserved. // // Copyright (c) 2015, 
+Red Hat, Inc.
+//
+// This program and the accompanying materials // are licensed and made 
+available under the terms and conditions of the BSD License // which 
+accompanies this distribution.  The full text of the license may be 
+found at // http://opensource.org/licenses/bsd-license.php
+//
+// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" 
+BASIS, // WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+//
+// **/
+
+#string STR_PROPERTIES_MODULE_NAME #language en-US "CpuS3DataDxe module"
+
+
--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] UefiCpuPkg/CpuMpPei: Fix pack(1) issue on x64 arch

[Fan, Jeff]

Mike,

Thanks your testing. I will add your comment when check-in the code.

Jeff

-Original Message-
From: Kinney, Michael D 
Sent: Friday, December 18, 2015 10:20 AM
To: Fan, Jeff; edk2-devel@lists.01.org; Kinney, Michael D
Cc: Tian, Feng; Justen, Jordan L
Subject: RE: [Patch] UefiCpuPkg/CpuMpPei: Fix pack(1) issue on x64 arch

Jeff,

With this change X64 OVMF boots.  Thanks for the quick fix.

Please add a comment above declaration of structure MP_CPU_EXCHANGE_INFO that 
the structure is required to be packed because fixed field offsets into this 
structure are used in assembly code in this module.

With that comment added:

Reviewed-by: Michael Kinney <michael.d.kin...@intel.com>

Mike

> -Original Message-
> From: Fan, Jeff
> Sent: Thursday, December 17, 2015 6:16 AM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng <feng.t...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; Justen, Jordan L 
> <jordan.l.jus...@intel.com>
> Subject: [Patch] UefiCpuPkg/CpuMpPei: Fix pack(1) issue on x64 arch
> 
> Packing alignment for MP_CPU_EXCHANGE_INFO should be 1. This should be 
> typo when check-in CpuMpPei driver. IA32 arch MP_CPU_EXCHANGE_INFO is 
> luckly pack(1). It leads CpuMpPei x64 version hung.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Reported-by: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> ---
>  UefiCpuPkg/CpuMpPei/CpuMpPei.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.h 
> b/UefiCpuPkg/CpuMpPei/CpuMpPei.h index f2286b9..2460f4a 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> @@ -72,7 +72,7 @@ typedef struct {
> 
>  typedef struct _PEI_CPU_MP_DATA  PEI_CPU_MP_DATA;
> 
> -#pragma pack()
> +#pragma pack(1)
> 
>  typedef union {
>struct {
> --
> 1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 1/3] DuetPkg: Fix GCC error to avoid the duplicated global variables in EfiLdr

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Wednesday, December 16, 2015 6:17 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 1/3] DuetPkg: Fix GCC error to avoid the duplicated 
global variables in EfiLdr

Move the global variable definitions into source code instead of head filer.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming@intel.com>
---
 DuetPkg/EfiLdr/EfiLdr.h| 3 ---
 DuetPkg/EfiLdr/EfiLoader.c | 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/DuetPkg/EfiLdr/EfiLdr.h b/DuetPkg/EfiLdr/EfiLdr.h index 
665f405..4f21cf3 100644
--- a/DuetPkg/EfiLdr/EfiLdr.h
+++ b/DuetPkg/EfiLdr/EfiLdr.h
@@ -80,9 +80,6 @@ typedef struct {
   BIOS_MEMORY_MAP_ENTRY MemoryMapEntry[1];  } BIOS_MEMORY_MAP;
 
-EFILDR_LOADED_IMAGEDxeCoreImage;
-EFILDR_LOADED_IMAGEDxeIplImage;
-
 typedef
 VOID
 (EFIAPI * EFI_MAIN_ENTRYPOINT) (
diff --git a/DuetPkg/EfiLdr/EfiLoader.c b/DuetPkg/EfiLdr/EfiLoader.c index 
6913027..b23966e 100644
--- a/DuetPkg/EfiLdr/EfiLoader.c
+++ b/DuetPkg/EfiLdr/EfiLoader.c
@@ -24,6 +24,9 @@ Revision History:
 #include "PeLoader.h"
 #include "LzmaDecompress.h"
 
+EFILDR_LOADED_IMAGEDxeCoreImage;
+EFILDR_LOADED_IMAGEDxeIplImage;
+
 VOID
 SystemHang (
   CHAR8*Message
--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 2/3] DuetPkg: Fix GCC error to avoid the duplicated global variable in SmbiosGenDxe

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Wednesday, December 16, 2015 6:18 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 2/3] DuetPkg: Fix GCC error to avoid the duplicated 
global variable in SmbiosGenDxe

Update SmbiosGenDxe to use UefiHiiServicesLib.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming@intel.com>
---
 DuetPkg/SmbiosGenDxe/SmbiosGen.c   | 11 ---
 DuetPkg/SmbiosGenDxe/SmbiosGen.h   |  1 +
 DuetPkg/SmbiosGenDxe/SmbiosGen.inf |  1 +
 3 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/DuetPkg/SmbiosGenDxe/SmbiosGen.c b/DuetPkg/SmbiosGenDxe/SmbiosGen.c
index 03e0936..393bb4d 100644
--- a/DuetPkg/SmbiosGenDxe/SmbiosGen.c
+++ b/DuetPkg/SmbiosGenDxe/SmbiosGen.c
@@ -18,7 +18,6 @@ Abstract:
 **/
 
 #include "SmbiosGen.h"
-EFI_HII_DATABASE_PROTOCOL   *gHiiDatabase;
 extern UINT8SmbiosGenDxeStrings[];
 EFI_SMBIOS_PROTOCOL *gSmbios;
 EFI_HII_HANDLE  gStringHandle;
@@ -211,16 +210,6 @@ SmbiosGenEntrypoint (
   if (EFI_ERROR (Status)) {
 return Status;
   }
-
-  Status = gBS->LocateProtocol (
-  ,
-  NULL,
-  (VOID**)
-  );
-
-  if (EFI_ERROR (Status)) {
-return Status;
-  }
   
   gStringHandle = HiiAddPackages (
 ,
diff --git a/DuetPkg/SmbiosGenDxe/SmbiosGen.h b/DuetPkg/SmbiosGenDxe/SmbiosGen.h
index 0474366..3a42e22 100644
--- a/DuetPkg/SmbiosGenDxe/SmbiosGen.h
+++ b/DuetPkg/SmbiosGenDxe/SmbiosGen.h
@@ -39,6 +39,7 @@ Abstract:
 #include 
 #include 
 #include 
+#include 
 
 #define   PRODUCT_NAME  L"DUET"
 #define   PRODUCT_VERSION   L"Beta"
diff --git a/DuetPkg/SmbiosGenDxe/SmbiosGen.inf 
b/DuetPkg/SmbiosGenDxe/SmbiosGen.inf
index e413beb..c8568da 100644
--- a/DuetPkg/SmbiosGenDxe/SmbiosGen.inf
+++ b/DuetPkg/SmbiosGenDxe/SmbiosGen.inf
@@ -41,6 +41,7 @@
   UefiDriverEntryPoint
   BaseLib
   HiiLib
+  UefiHiiServicesLib
   
 [Sources]
   SmbiosGen.c
-- 
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] UefiCpuPkg/CpuExceptionHandlerLib: Skip CR restore for SMM handler.

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Yao, Jiewen 
Sent: Thursday, November 26, 2015 8:34 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Fan, Jeff; Kinney, Michael D
Subject: [patch] UefiCpuPkg/CpuExceptionHandlerLib: Skip CR restore for SMM 
handler.

In SMM, we skip CR restore. The CR should always be right and should no be 
touched.
mDoFarReturnFlag is changed to mSmmFlag to indicate all difference between 
normal mode and SMM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen....@intel.com>
Cc: "Fan, Jeff" <jeff@intel.com>
Cc: "Kinney, Michael D" <michael.d.kin...@intel.com>
---
 .../Library/CpuExceptionHandlerLib/CpuExceptionCommon.h   |  2 +-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c  |  2 +-
 .../CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.S | 14 --
 .../CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.asm   | 14 --
 .../Library/CpuExceptionHandlerLib/SecPeiCpuException.c   |  2 +-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c  |  2 +-
 .../CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.S  | 15 +--
 .../CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.asm| 14 --
 8 files changed, 53 insertions(+), 12 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index b28e9c5..9fc0bd5 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -42,7 +42,7 @@ typedef struct {
 
 extern CONST UINT32mErrorCodeFlag;
 extern CONST UINTN mImageAlignSize;
-extern CONST UINTN mDoFarReturnFlag;
+extern CONST UINTN mSmmFlag;
 extern RESERVED_VECTORS_DATA   *mReservedVectors;
 
 /**
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
index 6739a2c..c11fb96 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 
-CONST UINTNmDoFarReturnFlag  = 0;
+CONST UINTNmSmmFlag  = 0;
 
 extern SPIN_LOCK   mDisplayMessageSpinLock;
 extern EFI_CPU_INTERRUPT_HANDLER   *mExternalInterruptHandler;
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.S 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.S
index 3676809..8d65e76 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.S
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm
+++ .S
@@ -26,7 +26,7 @@ ASM_GLOBAL ASM_PFX(CommonInterruptEntry)  ASM_GLOBAL 
ASM_PFX(HookAfterStubHeaderEnd)
 
 #EXTRN ASM_PFX(mErrorCodeFlag):DWORD   # Error code flags for 
exceptions
-#EXTRN ASM_PFX(mDoFarReturnFlag):DWORD # Do far return flag
+#EXTRN ASM_PFX(mSmmFlag):DWORD # Is it handler for SMM?
 
 .text
 
@@ -456,6 +456,7 @@ ErrorCodeAndVectorOnStack:
 popl%ebx # retore value of ebx that was 
overwritten
  # by CPUID 
 movl%cr4, %eax
+movl%eax, %ecx
 pushl   %eax # push cr4 firstly
 testl   $BIT24, %edx # Test for FXSAVE/FXRESTOR support
 jz  L1
@@ -465,7 +466,10 @@ L1:
 jz  L2
 orl $BIT3, %eax  # Set CR4.DE
 L2:
+cmpl%ecx, %eax
+jz  Cr4Done
 movl%eax, %cr4
+Cr4Done:
 movl%cr3, %eax
 pushl   %eax
 movl%cr2, %eax
@@ -536,6 +540,11 @@ L4:
 #; or debuggers set breakpoint in interrupt/exception context
 addl$24, %esp
 
+cmpl$0, ASM_PFX(mSmmFlag)   # Check if need skip WriteCr
+jz  CrRestore
+addl$20, %esp
+jmp CrDone
+CrRestore:
 #; UINT32  Cr0, Cr1, Cr2, Cr3, Cr4;
 popl%eax
 movl%eax, %cr0
@@ -546,6 +555,7 @@ L4:
 movl%eax, %cr3
 popl%eax
 movl%eax, %cr4
+CrDone:
 
 #; UINT32  EFlags;
 popl20(%ebp)
@@ -595,7 +605,7 @@ ErrorCode:
 jmp *-12(%esp)
 
 DoReturn:
-cmpl$0, ASM_PFX(mDoFarReturnFlag)
+cmpl$0, ASM_PFX(mSmmFlag)
 jz  DoIret
 pushl   8(%esp)   # save EFLAGS
 addl$16, %esp
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.asm 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.asm
index 12bbec0..177bdd9 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.asm
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm
+++ .asm
@@ -31,7 +31,7 @@ CommonExceptionHandler PROTO   C
 .data
 
 EXTRN mErrorCodeFlag:DWO

Re: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Move IDT to page aligned memory.

[Fan, Jeff]

Move IDT table to C code is very good! 

I think EFIAPI is no longer required for InitializeIDTSmmStackGuard().

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of jiewen 
yao
Sent: Thursday, November 26, 2015 4:59 PM
To: edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Yao, Jiewen; Fan, Jeff
Subject: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Move IDT to page aligned memory.

The IDT in ASM is removed. We rely on C code to allocate IDT.
We also move InitializeIDTSmmStackGuard() from ASM to C file.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen....@intel.com>
Cc: "Fan, Jeff" <jeff@intel.com>
Cc: "Kinney, Michael D" <michael.d.kin...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.S   | 224 +
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.asm |  34 +---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c   |  24 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c  |  13 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiException.S| 249 +---
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiException.asm  |  33 +---
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c|  21 ++
 7 files changed, 72 insertions(+), 526 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.S 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.S
index 4130bf5..eb41410 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.S
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.S
@@ -24,6 +24,7 @@ ASM_GLOBAL  ASM_PFX(PageFaultStubFunction)  ASM_GLOBAL  
ASM_PFX(gSmiMtrrs)  ASM_GLOBAL  ASM_PFX(gcSmiIdtr)  ASM_GLOBAL  
ASM_PFX(gcSmiGdtr)
+ASM_GLOBAL  ASM_PFX(gTaskGateDescriptor)
 ASM_GLOBAL  ASM_PFX(gcPsd)
 ASM_GLOBAL  ASM_PFX(FeaturePcdGet (PcdCpuSmmProfileEnable))
 
@@ -236,207 +237,10 @@ ASM_PFX(gcPsd):
 ASM_PFX(gcSmiGdtr):  .word  GDT_SIZE - 1
  .long  NullSeg
 
-ASM_PFX(gcSmiIdtr):  .word  IDT_SIZE - 1
- .long  _SmiIDT
-
-_SmiIDT:
-# The following segment repeats 32 times:
-# No. 1
-.word 0 # Offset 0:15
-.word  CODE_SEL
-.byte 0 # Unused
-.byte 0x8e  # Interrupt Gate, Present
-.word 0 # Offset 16:31
-# No. 2
-.word 0 # Offset 0:15
-.word  CODE_SEL
-.byte 0 # Unused
-.byte 0x8e  # Interrupt Gate, Present
-.word 0 # Offset 16:31
-# No. 3
-.word 0 # Offset 0:15
-.word  CODE_SEL
-.byte 0 # Unused
-.byte 0x8e  # Interrupt Gate, Present
-.word 0 # Offset 16:31
-# No. 4
-.word 0 # Offset 0:15
-.word  CODE_SEL
-.byte 0 # Unused
-.byte 0x8e  # Interrupt Gate, Present
-.word 0 # Offset 16:31
-# No. 5
-.word 0 # Offset 0:15
-.word  CODE_SEL
-.byte 0 # Unused
-.byte 0x8e  # Interrupt Gate, Present
-.word 0 # Offset 16:31
-# No. 6
-.word 0 # Offset 0:15
-.word  CODE_SEL
-.byte 0 # Unused
-.byte 0x8e  # Interrupt Gate, Present
-.word 0 # Offset 16:31
-# No. 7
-.word 0 # Offset 0:15
-.word  CODE_SEL
-.byte 0 # Unused
-.byte 0x8e  # Interrupt Gate, Present
-.word 0 # Offset 16:31
-# No. 8
-.word 0 # Offset 0:15
-.word  CODE_SEL
-.byte 0 # Unused
-.byte 0x8e  # Interrupt Gate, Present
-.word 0 # Offset 16:31
-# No. 9
-.word 0 # Offset 0:15
-.word  CODE_SEL
-.byte 0 # Unused
-.byte 0x8e  # Interrupt Gate, Present
-.word 0 # Offset 16:31
-# No. 10
-.word 0 # Offset 0:15
-.word  CODE_SEL
-.byte 0 # Unused
-.byte 0x8e  # Interrupt Gate, Present
-.word 0 # Offset 16:31
-# No. 11
-.word 0 # Offset 0:15
-.word  CODE_SEL
-.byte 0 # Unused
-.byte 0x8e  # Interrupt Gate, Present
-.word 

Re: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Move IDT to page aligned memory.

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Yao, Jiewen 
Sent: Wednesday, November 25, 2015 12:51 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Fan, Jeff; Kinney, Michael D
Subject: [patch] UefiCpuPkg/PiSmmCpu: Move IDT to page aligned memory.

The previous IDT is not in page aligned memory.
We allocate and copy it in page aligned memory, so that other program may use 
page level protection on that.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen....@intel.com>
Cc: "Fan, Jeff" <jeff@intel.com>
Cc: "Kinney, Michael D" <michael.d.kin...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index 06ffc6d..031a5fe 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -1218,6 +1218,7 @@ InitializeMpServiceData (
   PROCESSOR_SMM_DESCRIPTOR  *Psd;
   UINT8 *GdtTssTables;
   UINTN GdtTableStepSize;
+  VOID  *IdtBase;
 
   //
   // Initialize physical address mask
@@ -1232,6 +1233,14 @@ InitializeMpServiceData (
   //
   Cr3 = SmmInitPageTable ();
 
+  //
+  // Allocate and Copy because previous IdtBase might not be 4K aligned.
+  //
+  IdtBase  = AllocatePages (EFI_SIZE_TO_PAGES(gcSmiIdtr.Limit + 1));  
+ ASSERT (IdtBase != 0);  CopyMem (IdtBase, (VOID *)gcSmiIdtr.Base, 
+ gcSmiIdtr.Limit + 1);  gcSmiIdtr.Base = (UINTN)IdtBase;
+
   GdtTssTables = InitGdt (Cr3, );
 
   //
--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Remove TSS fixup in GDT.

[Fan, Jeff]

Jiewen,

Could you combine this patch with [patch] UefiCpuPkg/PiSmmCpu: Eliminate 
EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64)?

Reviewed-by: Jeff Fan <jeff@intel.com>

Jeff
-Original Message-
From: Yao, Jiewen 
Sent: Monday, November 23, 2015 10:15 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Fan, Jeff; Kinney, Michael D
Subject: [patch] UefiCpuPkg/PiSmmCpu: Remove TSS fixup in GDT.

The TSS is already fixed in PiSmmCpuDxeSmm/X64/SmmFuncsArch.c, InitGdt().
There is no need to fix it again.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yao, Jiewen <jiewen@intel.com>
Cc: Fan, Jeff <jeff@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S   | 8 
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm | 8 
 2 files changed, 16 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
index 8315593..95e6dfa 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
@@ -128,14 +128,6 @@ ASM_PFX(gSmiCr3):.space  4
 sgdt(%rsp)
 movl2(%rsp), %eax   # eax = GDT base
 addl$8, %esp
-movl%eax, %edx
-addl$GDT_SIZE, %edx
-movb%dl, (TSS_SEGMENT + 2)(%rax)
-movb%dh, (TSS_SEGMENT + 3)(%rax)
-.byte   0xc1, 0xea, 0x10 # shr edx, 16
-movb%dl, (TSS_SEGMENT + 4)(%rax)
-movb%dh, (TSS_SEGMENT + 7)(%rax)
-movl%eax, %edx
 movb$0x89, %dl
 movb%dl, (TSS_SEGMENT + 5)(%rax) # clear busy flag
 movl$TSS_SEGMENT, %eax
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
index c556bf5..4d53db5 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
@@ -124,14 +124,6 @@ gSmiCr3 DD  ?
 sgdtfword ptr [rsp]
 mov eax, [rsp + 2]  ; eax = GDT base
 add esp, 8
-mov edx, eax
-add edx, GDT_SIZE
-mov [rax + TSS_SEGMENT + 2], dl
-mov [rax + TSS_SEGMENT + 3], dh
-DB  0c1h, 0eah, 10h ; shr edx, 16
-mov [rax + TSS_SEGMENT + 4], dl
-mov [rax + TSS_SEGMENT + 7], dh
-mov edx, eax
 mov dl, 89h
 mov [rax + TSS_SEGMENT + 5], dl ; clear busy flag
 mov eax, TSS_SEGMENT
-- 
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if x2APIC supported

[Fan, Jeff]

Yes. I think so.

If x2APIC is supported by CPUID.(EAX=00H).ECX.BIT21, CPUID leaf 0x0B should be 
supported because x2APIC ID could be gotten from CPUID.(EAX=0BH, ECX=0H):EDX.
Otherwise, we cannot get x2APIC ID before we enabled x2APIC mode.

Jeff
-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, November 24, 2015 3:58 PM
To: Fan, Jeff; edk2-devel@lists.01.org; Kinney, Michael D
Cc: Tian, Feng
Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if 
x2APIC supported

Jeff,

Yes. That is ASSERT() location I was suggesting.

Does is also makes sense to fall back to GetInitialApicId() if CPUID leaf is 
not supported?  Or is this really a  condition that should never occur?

Mike

> -Original Message-
> From: Fan, Jeff
> Sent: Monday, November 23, 2015 11:38 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; 
> edk2-devel@lists.01.org
> Cc: Tian, Feng <feng.t...@intel.com>
> Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from 
> CPUID if x2APIC supported
> 
> Mike,
> 
> OK.  So,  if 0xB leaf is not supported, then ASSERT() in 
> GetX2ApicIdFromCpuId();
> 
>   //
>   // Get the maximum index of basic CPUID
>   //
>   AsmCpuid (CPUID_SIGNATURE, , NULL, NULL, NULL);
>   ASSERT (MaxCpuIdIndex >= CPUID_EXTENDED_TOPOLOGY);
> 
> Jeff
> 
> -Original Message-----
> From: Kinney, Michael D
> Sent: Tuesday, November 24, 2015 3:00 PM
> To: Fan, Jeff; edk2-devel@lists.01.org; Kinney, Michael D
> Cc: Tian, Feng
> Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from 
> CPUID if x2APIC supported
> 
> Jeff,
> 
> Can you move the ASSERT() for no APIC ID available into 
> GetX2ApicIdFromCpuId().  Then you do not need special APIC ID value of 
> 0x.
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Jeff Fan
> > Sent: Monday, November 23, 2015 12:06 AM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Tian, Feng 
> > <feng.t...@intel.com>
> > Subject: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from 
> > CPUID if x2APIC supported
> >
> > If x2APIC is supported by processor, get the APIC ID from 
> > CPUID.(EAX=0BH, ECX=0H):EDX instead of legacy APIC ID. It is used to check 
> > if need to enable x2APIC mode.
> >
> > Cc: Feng Tian <feng.t...@intel.com>
> > Cc: Michael Kinney <michael.d.kin...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jeff Fan <jeff@intel.com>
> > ---
> >  UefiCpuPkg/CpuMpPei/CpuMpPei.c | 65
> > --
> >  1 file changed, 63 insertions(+), 2 deletions(-)
> >
> > diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c 
> > b/UefiCpuPkg/CpuMpPei/CpuMpPei.c index 8e35f28..a301fe5 100644
> > --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> > +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> > @@ -102,6 +102,62 @@ SortApicId (
> >  }
> >
> >  /**
> > +  Check if x2APIC is supported by processor.
> > +
> > +  @retval  TRUEx2APIC is supported.
> > +  @retval  FALSE   x2APIC isn't supported.
> > +**/
> > +BOOLEAN
> > +IsX2ApicModeSupport (
> > +  VOID
> > +  )
> > +{
> > +  UINT32RegEcx;
> > +  //
> > +  // Check if processor supports x2APIC feature
> > +  //
> > +  AsmCpuid (CPUID_VERSION_INFO, NULL, NULL, , NULL);
> > +  if ((RegEcx & BIT21) != 0) {
> > +return TRUE;
> > +  } else {
> > +return FALSE;
> > +  }
> > +}
> > +
> > +/**
> > +  Return x2APIC ID from CPUID.
> > +
> > +  @retval -1  Invalid x2APIC ID
> > +  @retval others  x2APIC ID returned **/
> > +UINT32
> > +GetX2ApicIdFromCpuId (
> > +  VOID
> > +  )
> > +{
> > +  UINT32RegEdx;
> > +  UINT32MaxCpuIdIndex;
> > +
> > +  //
> > +  // The APIC ID value of _H is reserved and cannot be 
> > +assigned
> > +  // to any logical processor.
> > +  //
> > +  RegEdx = 0x;
> > +  //
> > +  // Get the maximum index of basic CPUID
> > +  //
> > +  AsmCpuid (CPUID_SIGNATURE, , NULL, NULL, NULL);
> > +  //
> > +  // If the extended topology enumeration leaf is available,
> > +  // get x2APIC ID from CPUID.(EAX=0BH, ECX=0H):EDX
> > +  //
> > +  if (MaxCpuIdIndex >= CPUID_EXTENDED_TOPOLOGY) {
> > +AsmCpuidEx (CPUID_EXTENDED_TOPOLOGY, 0, NULL, NULL, NULL,

Re: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if x2APIC supported

[Fan, Jeff]

Mike,

OK.  So,  if 0xB leaf is not supported, then ASSERT() in GetX2ApicIdFromCpuId();

  //
  // Get the maximum index of basic CPUID
  //
  AsmCpuid (CPUID_SIGNATURE, , NULL, NULL, NULL);
  ASSERT (MaxCpuIdIndex >= CPUID_EXTENDED_TOPOLOGY);

Jeff

-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, November 24, 2015 3:00 PM
To: Fan, Jeff; edk2-devel@lists.01.org; Kinney, Michael D
Cc: Tian, Feng
Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if 
x2APIC supported

Jeff,

Can you move the ASSERT() for no APIC ID available into GetX2ApicIdFromCpuId(). 
 Then you do not need special APIC ID value of 0x.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Jeff Fan
> Sent: Monday, November 23, 2015 12:06 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Tian, Feng 
> <feng.t...@intel.com>
> Subject: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from 
> CPUID if x2APIC supported
> 
> If x2APIC is supported by processor, get the APIC ID from 
> CPUID.(EAX=0BH, ECX=0H):EDX instead of legacy APIC ID. It is used to check if 
> need to enable x2APIC mode.
> 
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> ---
>  UefiCpuPkg/CpuMpPei/CpuMpPei.c | 65 
> --
>  1 file changed, 63 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c 
> b/UefiCpuPkg/CpuMpPei/CpuMpPei.c index 8e35f28..a301fe5 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> @@ -102,6 +102,62 @@ SortApicId (
>  }
> 
>  /**
> +  Check if x2APIC is supported by processor.
> +
> +  @retval  TRUEx2APIC is supported.
> +  @retval  FALSE   x2APIC isn't supported.
> +**/
> +BOOLEAN
> +IsX2ApicModeSupport (
> +  VOID
> +  )
> +{
> +  UINT32RegEcx;
> +  //
> +  // Check if processor supports x2APIC feature
> +  //
> +  AsmCpuid (CPUID_VERSION_INFO, NULL, NULL, , NULL);
> +  if ((RegEcx & BIT21) != 0) {
> +return TRUE;
> +  } else {
> +return FALSE;
> +  }
> +}
> +
> +/**
> +  Return x2APIC ID from CPUID.
> +
> +  @retval -1  Invalid x2APIC ID
> +  @retval others  x2APIC ID returned
> +**/
> +UINT32
> +GetX2ApicIdFromCpuId (
> +  VOID
> +  )
> +{
> +  UINT32RegEdx;
> +  UINT32MaxCpuIdIndex;
> +
> +  //
> +  // The APIC ID value of _H is reserved and cannot be 
> +assigned
> +  // to any logical processor.
> +  //
> +  RegEdx = 0x;
> +  //
> +  // Get the maximum index of basic CPUID
> +  //
> +  AsmCpuid (CPUID_SIGNATURE, , NULL, NULL, NULL);
> +  //
> +  // If the extended topology enumeration leaf is available,
> +  // get x2APIC ID from CPUID.(EAX=0BH, ECX=0H):EDX
> +  //
> +  if (MaxCpuIdIndex >= CPUID_EXTENDED_TOPOLOGY) {
> +AsmCpuidEx (CPUID_EXTENDED_TOPOLOGY, 0, NULL, NULL, NULL, 
> +);
> +  }
> +  return RegEdx;
> +}
> +
> +/**
>Get CPU MP Data pointer from the Guided HOB.
> 
>@return  Pointer to Pointer to PEI CPU MP Data @@ -146,11 +202,16 @@ 
> ApCFunction (
>PeiCpuMpData = ExchangeInfo->PeiCpuMpData;
>if (PeiCpuMpData->InitFlag) {
>  //
> -// This is first time AP wakeup, get BIST inforamtion from AP stack
> +// This is first time AP wakeup, get BIST information from AP 
> + stack
>  //
>  BistData = *(UINTN *) (PeiCpuMpData->Buffer + NumApsExecuting * 
> PeiCpuMpData->CpuApStackSize - sizeof (UINTN));
> -PeiCpuMpData->CpuData[NumApsExecuting].ApicId= GetInitialApicId 
> ();
>  PeiCpuMpData->CpuData[NumApsExecuting].Health.Uint32 = (UINT32) 
> BistData;
> +if (!IsX2ApicModeSupport()) {
> +  PeiCpuMpData->CpuData[NumApsExecuting].ApicId = GetInitialApicId ();
> +} else {
> +  PeiCpuMpData->CpuData[NumApsExecuting].ApicId = GetX2ApicIdFromCpuId 
> ();
> +  ASSERT (PeiCpuMpData->CpuData[NumApsExecuting].ApicId != 0x);
> +}
>  //
>  // Sync BSP's Mtrr table to all wakeup APs and load microcode on APs.
>  //
> --
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if x2APIC supported

[Fan, Jeff]

Mike,

OK. I got your point.

I just reviewed the GetInitialApicId(). It has already check CPUID leaf 0B to 
get x2APIC ID if leaf 0B supported.
//
// Get the max index of basic CPUID
//
AsmCpuid (CPUID_SIGNATURE, , NULL, NULL, NULL);
//
// If CPUID Leaf B is supported, 
// Then the initial 32-bit APIC ID = CPUID.0BH:EDX
// Else the initial 8-bit APIC ID = CPUID.1:EBX[31:24]
//
if (MaxCpuIdIndex >= CPUID_EXTENDED_TOPOLOGY) {
  AsmCpuidEx (CPUID_EXTENDED_TOPOLOGY, 0, NULL, NULL, NULL, );
  return ApicId;
}
AsmCpuid (CPUID_VERSION_INFO, NULL, , NULL, NULL);
return RegEbx >> 24;

That means CpuMpPei needn't to get check x2APIC and CPUID leaf 0B again. It 
only just check if InitialApicId larger than 0xFE or not.

Thanks!
Jeff

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fan, Jeff
Sent: Tuesday, November 24, 2015 4:03 PM
To: Kinney, Michael D; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: Re: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if 
x2APIC supported

Yes. I think so.

If x2APIC is supported by CPUID.(EAX=00H).ECX.BIT21, CPUID leaf 0x0B should be 
supported because x2APIC ID could be gotten from CPUID.(EAX=0BH, ECX=0H):EDX.
Otherwise, we cannot get x2APIC ID before we enabled x2APIC mode.

Jeff
-Original Message-
From: Kinney, Michael D
Sent: Tuesday, November 24, 2015 3:58 PM
To: Fan, Jeff; edk2-devel@lists.01.org; Kinney, Michael D
Cc: Tian, Feng
Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if 
x2APIC supported

Jeff,

Yes. That is ASSERT() location I was suggesting.

Does is also makes sense to fall back to GetInitialApicId() if CPUID leaf is 
not supported?  Or is this really a  condition that should never occur?

Mike

> -Original Message-----
> From: Fan, Jeff
> Sent: Monday, November 23, 2015 11:38 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; 
> edk2-devel@lists.01.org
> Cc: Tian, Feng <feng.t...@intel.com>
> Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from 
> CPUID if x2APIC supported
> 
> Mike,
> 
> OK.  So,  if 0xB leaf is not supported, then ASSERT() in 
> GetX2ApicIdFromCpuId();
> 
>   //
>   // Get the maximum index of basic CPUID
>   //
>   AsmCpuid (CPUID_SIGNATURE, , NULL, NULL, NULL);
>   ASSERT (MaxCpuIdIndex >= CPUID_EXTENDED_TOPOLOGY);
> 
> Jeff
> 
> -Original Message-
> From: Kinney, Michael D
> Sent: Tuesday, November 24, 2015 3:00 PM
> To: Fan, Jeff; edk2-devel@lists.01.org; Kinney, Michael D
> Cc: Tian, Feng
> Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from 
> CPUID if x2APIC supported
> 
> Jeff,
> 
> Can you move the ASSERT() for no APIC ID available into 
> GetX2ApicIdFromCpuId().  Then you do not need special APIC ID value of 
> 0x.
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Jeff Fan
> > Sent: Monday, November 23, 2015 12:06 AM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Tian, Feng 
> > <feng.t...@intel.com>
> > Subject: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from 
> > CPUID if x2APIC supported
> >
> > If x2APIC is supported by processor, get the APIC ID from 
> > CPUID.(EAX=0BH, ECX=0H):EDX instead of legacy APIC ID. It is used to check 
> > if need to enable x2APIC mode.
> >
> > Cc: Feng Tian <feng.t...@intel.com>
> > Cc: Michael Kinney <michael.d.kin...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jeff Fan <jeff@intel.com>
> > ---
> >  UefiCpuPkg/CpuMpPei/CpuMpPei.c | 65
> > --
> >  1 file changed, 63 insertions(+), 2 deletions(-)
> >
> > diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c 
> > b/UefiCpuPkg/CpuMpPei/CpuMpPei.c index 8e35f28..a301fe5 100644
> > --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> > +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> > @@ -102,6 +102,62 @@ SortApicId (
> >  }
> >
> >  /**
> > +  Check if x2APIC is supported by processor.
> > +
> > +  @retval  TRUEx2APIC is supported.
> > +  @retval  FALSE   x2APIC isn't supported.
> > +**/
> > +BOOLEAN
> > +IsX2ApicModeSupport (
> > +  VOID
> > +  )
> > +{
> > +  UINT32RegEcx;
> > +  //
> > +  // Check if processor supports x2APIC feature
> > +  //
> > +  AsmCpuid (CPUID_VERSION_INFO, NULL, NULL, , NULL);
> > +  if ((RegEcx & BIT21) != 0) {
> > +return TRUE;
> > +  } else

Re: [edk2] [PATCH 0/2] UefiCpuPkg, OvmfPkg: prevent (unchecked) SMM stack overflow

[Fan, Jeff]

Laszlo,

I agree. Please go ahead to check-in this serial of patches. We may revisit it 
if we receive other concern in the future.

Thanks!
Jeff

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, June 02, 2016 6:13 PM
To: Fan, Jeff; edk2-devel-01
Cc: Yao, Jiewen; Justen, Jordan L; Kinney, Michael D
Subject: Re: [PATCH 0/2] UefiCpuPkg, OvmfPkg: prevent (unchecked) SMM stack 
overflow

On 06/02/16 04:15, Fan, Jeff wrote:
> Reviewed-by: Jeff Fan <jeff@intel.com>
> 
> Good suggestion to set PcdCpuSmmStackGuard default to TRUE. 

Thanks!

> But please hold on the check-in in UefiCpuPkg.dec till next week, I 
> want more platforms to be validated on this change.

Actually, even if this change causes problems for those out-of-tree platforms, 
I think it should be committed to the open source repo, and those other 
platforms should set PcdCpuSmmStackGuard to FALSE in their DSC files.

This is actually the entire point of writing patch #1 for UefiCpuPkg (the .dec 
file) and not for the OVMF DSC files. I don't just want to make it safe for 
OVMF -- instead, I'd like to make it safe for all other future platforms that 
consume the open source edk2 tree, so that their developers don't have to go 
through the same analysis that I had to.

This is what "opt out" means -- if PcdCpuSmmStackGuard=TRUE breaks those 
external platforms, then
(a) they should be fixed anyway, or
(b) if they aren't broken, just cannot afford the extra guard page, then they 
should opt out of the stack guard.

I'm aware that this could be an incompatible change for external platforms with 
a very tight SMRAM budget, but even that way, it is the right thing to do in 
the open source tree, for future consumers of edk2.

Thanks
Laszlo

> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, June 02, 2016 3:03 AM
> To: edk2-devel-01
> Cc: Fan, Jeff; Yao, Jiewen; Justen, Jordan L; Kinney, Michael D
> Subject: [PATCH 0/2] UefiCpuPkg, OvmfPkg: prevent (unchecked) SMM 
> stack overflow
> 
> These patches are the result of the investigation at 
> <http://thread.gmane.org/gmane.comp.bios.edk2.devel/12864>.
> 
> Cc: Jeff Fan <jeff@intel.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Michael D Kinney <michael.d.kin...@intel.com>
> 
> Laszlo Ersek (2):
>   UefiCpuPkg: change PcdCpuSmmStackGuard default to TRUE
>   OvmfPkg: set SMM stack size to 16KB
> 
>  UefiCpuPkg/UefiCpuPkg.dec  | 4 ++--
>  OvmfPkg/OvmfPkgIa32.dsc| 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>  OvmfPkg/OvmfPkgX64.dsc | 1 +
>  4 files changed, 5 insertions(+), 2 deletions(-)
> 
> --
> 1.8.3.1
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] UefiCpuPkg, OvmfPkg: prevent (unchecked) SMM stack overflow

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

Good suggestion to set PcdCpuSmmStackGuard default to TRUE. 

But please hold on the check-in in UefiCpuPkg.dec till next week, I want more 
platforms to be validated on this change.

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, June 02, 2016 3:03 AM
To: edk2-devel-01
Cc: Fan, Jeff; Yao, Jiewen; Justen, Jordan L; Kinney, Michael D
Subject: [PATCH 0/2] UefiCpuPkg, OvmfPkg: prevent (unchecked) SMM stack overflow

These patches are the result of the investigation at 
<http://thread.gmane.org/gmane.comp.bios.edk2.devel/12864>.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Michael D Kinney <michael.d.kin...@intel.com>

Laszlo Ersek (2):
  UefiCpuPkg: change PcdCpuSmmStackGuard default to TRUE
  OvmfPkg: set SMM stack size to 16KB

 UefiCpuPkg/UefiCpuPkg.dec  | 4 ++--
 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 4 files changed, 5 insertions(+), 2 deletions(-)

--
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 0/9] UefiCpuPkg/PeiCpuExceptionHandlerLib

[Fan, Jeff]

Thanks your comments. I will check-in the patches after updated them per your 
comments.

-Original Message-
From: Tian, Feng 
Sent: Wednesday, June 01, 2016 1:56 PM
To: Fan, Jeff; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: RE: [edk2] [Patch 0/9] UefiCpuPkg/PeiCpuExceptionHandlerLib

Hi, Jeff

In patch #1, I didn't see you update the file comments to show it support PEI 
phase.
In patch #8, suggest to move the HOB_GUID definition to ExceptionCommon.h file.

If you fix them, you can have my RB.

Reviewed-by: Feng Tian <feng.t...@intel.com>

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff Fan
Sent: Wednesday, May 25, 2016 12:56 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 0/9] UefiCpuPkg/PeiCpuExceptionHandlerLib

Add one new PeiCpuExceptionHandlerLib. It is used to be linked by CpuMpPei 
module to register CPU exception handler. It could handle reserved vector list 
and use spin lock to prevent dump message corrupted when BSP/APs encounter the 
exception simultaneously.

Jeff Fan (9):
  UefiCpuPkg/ExceptionLib: Rename DxeSmmCpuException.c
  UefiCpuPkg/ExceptionLib: Add EXCEPTION_HANDLER_DATA definition
  UefiCpuPkg/ExceptionLib: Update InitializeCpuExceptionHandlersWorker
  UefiCpuPkg/ExceptionLib: Update UpdateIdtTable()
  UefiCpuPkg/ExceptionLib: Update RegisterCpuInterruptHandlerWorker()
  UefiCpuPkg/ExceptionLib: Add CommonExceptionHandlerWorker()
  UefiCpuPkg/ExceptionLib: Move global variable location
  UefiCpuPkg/ExceptionLib: Import PeiCpuExceptionHandlerLib module
  UefiCpuPkg/CpuMpPei: Consume CpuExceptionHandlerLib

 UefiCpuPkg/CpuMpPei/CpuMpPei.c |  21 +-
 UefiCpuPkg/CpuMpPei/CpuMpPei.h |   4 +-
 UefiCpuPkg/CpuMpPei/CpuMpPei.inf   |   5 +-
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++-
 .../DxeCpuExceptionHandlerLib.inf  |   4 +-
 .../Library/CpuExceptionHandlerLib/DxeException.c  |  62 -
 .../CpuExceptionHandlerLib/DxeSmmCpuException.c| 292 
 .../CpuExceptionHandlerLib/PeiCpuException.c   | 188 +
 .../PeiCpuExceptionHandlerLib.inf  |  61 +
 .../PeiCpuExceptionHandlerLib.uni  |  22 ++
 .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c | 294 +
 .../SmmCpuExceptionHandlerLib.inf  |   4 +-
 .../Library/CpuExceptionHandlerLib/SmmException.c  |  38 ++-
 UefiCpuPkg/UefiCpuPkg.dsc  |   2 +
 14 files changed, 718 insertions(+), 329 deletions(-)  delete mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeSmmCpuException.c
 create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.uni
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c

--
2.7.4.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] a "strange" branch taken in the SMM fault handler in PiSmmCpuDxe

[Fan, Jeff]

Laszlo,

Have you any clue on bisect this issue?

SmiDefaultPFHandler() is used to dynamically setup page entry for those address 
> 4GBytes.

If your platform is really accessing > 4GBytes address, Page Fault happened 
does make sense.
Otherwise, please check PFAddress value to understand why PFAddress > 4GBytes 
is access.

PageTable[PTIndex] = 7FFF2251 is not one valid page entry. 
Usually, we encountered the similar issue due to SMM page table room was 
crashed.

Thanks!
Jeff

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Tuesday, May 31, 2016 8:20 PM
To: Kinney, Michael D
Cc: Paolo Bonzini; edk2-devel-01; Radim Krcmár
Subject: Re: [edk2] a "strange" branch taken in the SMM fault handler in 
PiSmmCpuDxe

On 05/31/16 13:42, Laszlo Ersek wrote:
> Hello Mike,
> 
> our virt-QE team reported an interesting issue:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1308678#c14
> 
> We have a small UEFI_APPLICATION ((open source, of course) that 
> enrolls a set of fixed certificates into PK / KEK / DB.
> 
> In the course of the gRT->SetVariable() call, using the SMM driver 
> stack, the fault handler function that is used in SMM is invoked:
> SmiDefaultPFHandler() in "UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c".
> 
> Now, I have no clue about any situation when this fault handler should 
> be invoked as part of normal operation -- perhaps there are such cases.
> But, in this instance, the function seems to walk the page tables, 
> find the PTE, and realize that the Present bit is set in the PTE. Then it 
> prints:
> 
>   PageTable = 7FFA6000, PTIndex = 1FF, PageTable[PTIndex] = 7FFF2251
>   New page table overlapped with old page table!
> 
> The code that prints this has a comment (rewrapped here for readability):
> 
> //
> // Check if the entry has already existed, this issue may occur when 
> the // different size page entries created under the same entry //
> 
> Can you please help me interpret this? Is it related to 2MB / 1GB 
> pages, as opposed to 4KB pages? Or should I be looking for a genuine 
> fault in the variable driver?
> 
> I've never seen this issue, and in my normal work environment I can't 
> reproduce it. In the report linked above, I noticed
> 
>   -cpu IvyBridge
> 
> which makes QEMU emulate "Intel Xeon E3-12xx v2 (Ivy Bridge)".
> 
> Whereas my laptop has a Haswell CPU ("i7-4810MQ"), and with the 
> virtual machines I use for testing, I (or rather libvirtd) doesn't 
> pass any particular -cpu switch to QEMU. That seems to imply "qemu64" 
> ("QEMU Virtual CPU version 2.5+").
> 
> ... I've now tried with "-cpu IvyBridge" myself; I still can't reproduce it.

Hold on, I can reproduce it actually, regardless of CPU type. It seems to be an 
edk2 regression somewhere between d7c0dfa and 90bb4c5, that has been fixed 
between 90bb4c5 and current master (2f7b34b20). I'll try to bisect it.

Thanks!
Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS check.

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Yao, Jiewen 
Sent: Wednesday, June 29, 2016 10:30 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff; Kinney, Michael D
Subject: [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS 
check.

PI specification Vol 4 - SMM does not have any limitation of BASE_4GB for SMM.
So we should replace BASE_4GB check with MAX_ADDRESS check to make sure the SMM 
memory is accessible by SMM Core.

Cc: Jeff Fan <jeff@intel.com>
Cc: Michael D Kinney <michael.d.kin...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen@intel.com>
---
 MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 2 +-
 MdeModulePkg/Core/PiSmmCore/Pool.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
index acfcc83..3788bd5 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
@@ -1556,7 +1556,7 @@ SmmIplEntry (
 }
 
 if (gSmmCorePrivate->SmramRanges[Index].CpuStart >= BASE_1MB) {
-  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
gSmmCorePrivate->SmramRanges[Index].PhysicalSize) <= BASE_4GB) {
+  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
+ gSmmCorePrivate->SmramRanges[Index].PhysicalSize) <= MAX_ADDRESS) {
 if (gSmmCorePrivate->SmramRanges[Index].PhysicalSize >= MaxSize) {
   MaxSize = gSmmCorePrivate->SmramRanges[Index].PhysicalSize;
   mCurrentSmramRange = >SmramRanges[Index];
diff --git a/MdeModulePkg/Core/PiSmmCore/Pool.c 
b/MdeModulePkg/Core/PiSmmCore/Pool.c
index 761988e..e493fd2 100644
--- a/MdeModulePkg/Core/PiSmmCore/Pool.c
+++ b/MdeModulePkg/Core/PiSmmCore/Pool.c
@@ -67,7 +67,7 @@ SmmInitializeMemoryServices (
   }
 
   if (SmramRanges[Index].CpuStart >= BASE_1MB) {
-if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize) <= 
BASE_4GB) {
+if ((SmramRanges[Index].CpuStart + 
+ SmramRanges[Index].PhysicalSize) <= MAX_ADDRESS) {
   if (SmramRanges[Index].PhysicalSize >= MaxSize) {
 MaxSize = SmramRanges[Index].PhysicalSize;
 CurrentSmramRangesIndex = Index;
--
2.7.4.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v2 2/2] UefiCpuPkg/Cpuid: Add UEFI CPUID application

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Kinney, Michael D 
Sent: Wednesday, February 24, 2016 2:00 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff; Yao, Jiewen
Subject: [Patch v2 2/2] UefiCpuPkg/Cpuid: Add UEFI CPUID application

Add UEFI application to UefiCpuPkg to display all supported CPUID
leafs and sub-leafs described by UefiCpuPkg/Include/Register/Cpuid.h
that is based on information from Intel(R) 64 and IA-32
Architectures Software Developer's Manual, Volume 2A, December
2015, CPUID instruction.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 UefiCpuPkg/Application/Cpuid/Cpuid.c| 1353 +++
 UefiCpuPkg/Application/Cpuid/Cpuid.inf  |   48 +
 UefiCpuPkg/Application/Cpuid/Cpuid.uni  |   22 +
 UefiCpuPkg/Application/Cpuid/CpuidExtra.uni |   22 +
 UefiCpuPkg/UefiCpuPkg.dsc   |5 +
 5 files changed, 1450 insertions(+)
 create mode 100644 UefiCpuPkg/Application/Cpuid/Cpuid.c
 create mode 100644 UefiCpuPkg/Application/Cpuid/Cpuid.inf
 create mode 100644 UefiCpuPkg/Application/Cpuid/Cpuid.uni
 create mode 100644 UefiCpuPkg/Application/Cpuid/CpuidExtra.uni

diff --git a/UefiCpuPkg/Application/Cpuid/Cpuid.c 
b/UefiCpuPkg/Application/Cpuid/Cpuid.c
new file mode 100644
index 000..f82e43f
--- /dev/null
+++ b/UefiCpuPkg/Application/Cpuid/Cpuid.c
@@ -0,0 +1,1353 @@
+/** @file
+  UEFI Application to display CPUID leaf information.
+
+  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+///
+/// Macro used to display the value of a bit field in a register returned by 
CPUID.
+///
+#define PRINT_BIT_FIELD(Variable, FieldName) \
+  Print (L"%5a%42a: %x\n", #Variable, #FieldName, ##Variable.Bits.##FieldName);
+
+///
+/// Macro used to display the value of a register returned by CPUID.
+///
+#define PRINT_VALUE(Variable, Description) \
+  Print (L"%5a%42a: %x\n", #Variable, #Description, Variable);
+
+///
+/// Structure for cache description lookup table
+///
+typedef struct {
+  UINT8  CacheDescriptor;
+  CHAR8  *Type;
+  CHAR8  *Description;
+} CPUID_CACHE_INFO_DESCRIPTION;
+
+///
+/// Cache description lookup table
+///
+CPUID_CACHE_INFO_DESCRIPTION  mCpuidCacheInfoDescription[] = {
+  { 0x00 , "General"  , "Null descriptor, this byte contains no information" },
+  { 0x01 , "TLB"  , "Instruction TLB: 4 KByte pages, 4-way set 
associative, 32 entries" },
+  { 0x02 , "TLB"  , "Instruction TLB: 4 MByte pages, fully associative, 2 
entries" },
+  { 0x03 , "TLB"  , "Data TLB: 4 KByte pages, 4-way set associative, 64 
entries" },
+  { 0x04 , "TLB"  , "Data TLB: 4 MByte pages, 4-way set associative, 8 
entries" },
+  { 0x05 , "TLB"  , "Data TLB1: 4 MByte pages, 4-way set associative, 32 
entries" },
+  { 0x06 , "Cache", "1st-level instruction cache: 8 KBytes, 4-way set 
associative, 32 byte line size" },
+  { 0x08 , "Cache", "1st-level instruction cache: 16 KBytes, 4-way set 
associative, 32 byte line size" },
+  { 0x09 , "Cache", "1st-level instruction cache: 32KBytes, 4-way set 
associative, 64 byte line size" },
+  { 0x0A , "Cache", "1st-level data cache: 8 KBytes, 2-way set 
associative, 32 byte line size" },
+  { 0x0B , "TLB"  , "Instruction TLB: 4 MByte pages, 4-way set 
associative, 4 entries" },
+  { 0x0C , "Cache", "1st-level data cache: 16 KBytes, 4-way set 
associative, 32 byte line size" },
+  { 0x0D , "Cache", "1st-level data cache: 16 KBytes, 4-way set 
associative, 64 byte line size" },
+  { 0x0E , "Cache", "1st-level data cache: 24 KBytes, 6-way set 
associative, 64 byte line size" },
+  { 0x1D , "Cache", "2nd-level cache: 128 KBytes, 2-way set associative, 
64 byte line size" },
+  { 0x21 , "Cache", "2nd-level cache: 256 KBytes, 8-way set associative, 
64 byte line size" },
+  { 0x22 , "Cache", "3rd-level cache: 512 KBytes, 4-way set associative, 
64 byte line size, 2 lines per sector" },
+  { 0x23 , "Cache", "3rd-level 

Re: [edk2] [Patch v2 1/2] UefiCpuPkg/Cpuid.h: Add CPUID leaf/sub-leaf defines and structures

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Kinney, Michael D 
Sent: Wednesday, February 24, 2016 2:00 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff; Yao, Jiewen
Subject: [Patch v2 1/2] UefiCpuPkg/Cpuid.h: Add CPUID leaf/sub-leaf defines and 
structures

Add CPUID leaf and sub-leaf indexes and structures as described by
Intel(R) 64 and IA-32 Architectures Software Developer's Manual,
Volume 2A, December 2015, CPUID instruction.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 UefiCpuPkg/Include/Register/Cpuid.h | 3120 ++-
 1 file changed, 3097 insertions(+), 23 deletions(-)

diff --git a/UefiCpuPkg/Include/Register/Cpuid.h 
b/UefiCpuPkg/Include/Register/Cpuid.h
index f8ff247..4a5bc73 100644
--- a/UefiCpuPkg/Include/Register/Cpuid.h
+++ b/UefiCpuPkg/Include/Register/Cpuid.h
@@ -1,53 +1,3127 @@
 /** @file
-CPUID Definitions.
+  CPUID leaf definitions.
 
-CPUID definitions based on contents of the Intel(R) 64 and IA-32 Architectures
-Software Developer's Manual, Volume 2A, CPUID instruction.
+  Provides defines for CPUID leaf indexes.  Data structures are provided for
+  registers returned by a CPUID leaf that contain one or more bit fields.
+  If a register returned is a single 32-bit value, then a data structure is
+  not provided for that register.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
-This program and the accompanying materials
-are licensed and made available under the terms and conditions of the BSD 
License
-which accompanies this distribution.  The full text of the license may be 
found at
-http://opensource.org/licenses/bsd-license.php
+  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+  This program and the accompanying materials are licensed and made available 
under
+  the terms and conditions of the BSD License which accompanies this 
distribution.
+  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
 
-THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+  @par Specification Reference:
+  Intel(R) 64 and IA-32 Architectures Software Developer's Manual, Volume 2A,
+  December 2015, CPUID instruction.
 
 **/
 
 #ifndef __CPUID_H__
 #define __CPUID_H__
 
-//
-// Definitions for CPUID instruction
-//
-#define CPUID_SIGNATURE 0x0
+/**
+  CPUID Signature Information
+
+  @param   EAX  CPUID_SIGNATURE (0x00)
+
+  @retval  EAX  Returns the highest value the CPUID instruction recognizes for
+returning basic processor information. The value is returned is
+processor specific.
+  @retval  EBX  First 4 characters of a vendor identification string.
+  @retval  ECX  Last 4 characters of a vendor identification string.
+  @retval  EDX  Middle 4 characters of a vendor identification string.
+
+  Example usage
+  @code
+  UINT32 Eax;
+  UINT32 Ebx;
+  UINT32 Ecx;
+  UINT32 Edx;
+
+  AsmCpuid (CPUID_SIGNATURE, , , , );
+  @endcode
+**/
+#define CPUID_SIGNATURE 0x00
+
+///
+/// @{ CPUID signature values returned by Intel processors
+///
+#define CPUID_SIGNATURE_GENUINE_INTEL_EBX  SIGNATURE_32 ('G', 'e', 'n', 'u')
+#define CPUID_SIGNATURE_GENUINE_INTEL_EDX  SIGNATURE_32 ('i', 'n', 'e', 'I')
+#define CPUID_SIGNATURE_GENUINE_INTEL_ECX  SIGNATURE_32 ('n', 't', 'e', 'l')
+///
+/// @}
+///
+
+
+/**
+  CPUID Version Information
+
+  @param   EAX  CPUID_VERSION_INFO (0x01)
+
+  @retval  EAX  Returns Model, Family, Stepping Information described by the
+type CPUID_VERSION_INFO_EAX.
+  @retval  EBX  Returns Brand, Cache Line Size, and Initial APIC ID described 
by
+the type CPUID_VERSION_INFO_EBX.
+  @retval  ECX  CPU Feature Information described by the type
+CPUID_VERSION_INFO_ECX.
+  @retval  EDX  CPU Feature Information described by the type
+CPUID_VERSION_INFO_EDX.
+
+  Example usage
+  @code
+  CPUID_VERSION_INFO_EAX  Eax;
+  CPUID_VERSION_INFO_EBX  Ebx;
+  CPUID_VERSION_INFO_ECX  Ecx;
+  CPUID_VERSION_INFO_EDX  Edx;
+
+  AsmCpuid (CPUID_VERSION_INFO, , , , 
);
+  @endcode
+**/
+#define CPUID_VERSION_INFO  0x01
+
+/**
+  CPUID Version Information returned in EAX for CPUID leaf
+  #CPUID_VERSION_INFO.
+**/
+typedef union {
+  ///
+  /// Individual bit fields
+  ///
+  struct {
+UINT32  SteppingId:4;///< [Bits   3:0] Stepping ID
+UINT32  Model:4; ///< [Bits   7:4] Model
+UINT32  FamilyId:4;  ///< [Bits  11:8] Family
+UIN

Re: [edk2] [Patch 0/2] UefiCpuPkg: Update CPUID include file and add CPUID app

[Fan, Jeff]

It seems missing .uni files for Cpuid App module.

-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, February 23, 2016 5:49 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff; Yao, Jiewen
Subject: [Patch 0/2] UefiCpuPkg: Update CPUID include file and add CPUID app

This patch series updates the Cpuid.h file in UefiCpuPkg to describe all CPUID 
leafs and sub-leafs.  It also adds a UEFI CPUID application that tests the 
updated Cpuid.h file by displaying all the CPUID leafs and sub-leafs.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>

Michael Kinney (2):
  UefiCpuPkg/Cpuid.h: Add CPUID leaf/sub-leaf defines and structures
  UefiCpuPkg/Cpuid: Add UEFI CPUID application

 UefiCpuPkg/Application/Cpuid/Cpuid.c   | 1353 ++
 UefiCpuPkg/Application/Cpuid/Cpuid.inf |   39 +
 UefiCpuPkg/Include/Register/Cpuid.h| 3120 +++-
 UefiCpuPkg/UefiCpuPkg.dsc  |5 +
 4 files changed, 4494 insertions(+), 23 deletions(-)  create mode 100644 
UefiCpuPkg/Application/Cpuid/Cpuid.c
 create mode 100644 UefiCpuPkg/Application/Cpuid/Cpuid.inf

--
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Maintainers.txt: Update maintainers for SourceLevelDebugPkg

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Wu, Hao A 
Sent: Tuesday, January 19, 2016 11:44 AM
To: edk2-devel@lists.01.org; Fan, Jeff; Gao, Liming; Tian, Hot
Cc: Wu, Hao A
Subject: [PATCH] Maintainers.txt: Update maintainers for SourceLevelDebugPkg

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a...@intel.com>
---
 Maintainers.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Maintainers.txt b/Maintainers.txt index dc0891e..1095fe0 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -191,6 +191,7 @@ M: Shumin Qiu <shumin@intel.com>  SourceLevelDebugPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg
 M: Jeff Fan <jeff@intel.com>
+M: Hao Wu <hao.a...@intel.com>
 
 StdLib, StdLibPrivateInternalFiles
 W: https://github.com/tianocore/tianocore.github.io/wiki/StdLib
--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: Add invocation register support in SMM Communication ACPI Table

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Wu, Hao A 
Sent: Tuesday, February 16, 2016 11:10 AM
To: edk2-devel@lists.01.org; Fan, Jeff; Gao, Liming; Kinney, Michael D
Cc: Wu, Hao A
Subject: [PATCH] MdePkg: Add invocation register support in SMM Communication 
ACPI Table

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a...@intel.com>
---
 MdePkg/Include/Uefi/UefiAcpiDataTable.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Uefi/UefiAcpiDataTable.h 
b/MdePkg/Include/Uefi/UefiAcpiDataTable.h
index 30a5355..957721f 100644
--- a/MdePkg/Include/Uefi/UefiAcpiDataTable.h
+++ b/MdePkg/Include/Uefi/UefiAcpiDataTable.h
@@ -1,7 +1,7 @@
 /** @file
   UEFI ACPI Data Table Definition.
 
-Copyright (c) 2011, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under  the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at @@ -30,6 +30,11 @@ typedef struct 
{
   UINT64   BufferPtrAddress;
 } EFI_SMM_COMMUNICATION_ACPI_TABLE;
 
+typedef struct {
+  EFI_SMM_COMMUNICATION_ACPI_TABLEUefiSmmCommunicationAcpiTable;
+  EFI_ACPI_6_0_GENERIC_ADDRESS_STRUCTURE  InvocationRegister; } 
+EFI_SMM_COMMUNICATION_ACPI_TABLE_2;
+
 ///
 /// To avoid confusion in interpreting frames, the communication buffer should 
always  /// begin with EFI_SMM_COMMUNICATE_HEADER
--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to CheckFeatureSupported()

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Kinney, Michael D 
Sent: Friday, February 19, 2016 3:42 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff; Yao, Jiewen
Subject: [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to 
CheckFeatureSupported()

The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE in the MP 
Services Protocol service StartAllAPs().  Any function used as an 
EFI_AP_SERVICE must use EFIAPI calling convention.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 3 ++-  
UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index ec4ec9b..0279f89 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -1,7 +1,7 @@
 /** @file
 Enable SMM profile.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -930,6 +930,7 @@ 
InitSmmProfileInternal (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
   VOID
   )
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
index 4548467..5cb8d7c 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
@@ -1,7 +1,7 @@
 /** @file
 SMM profile header file.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -97,6 +97,7 @@ 
PageFaultIdtHandlerSmmProfile (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
   VOID
   );
--
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to CheckFeatureSupported()

[Fan, Jeff]

Laszlo,

Good catch. I agree it should be

VOID
EFIAPI
CheckFeatureSupported (
  IN OUT VOID  *Buffer
  );

Jeff
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, February 19, 2016 4:09 AM
To: Kinney, Michael D; edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Fan, Jeff
Subject: Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to 
CheckFeatureSupported()

On 02/18/16 20:41, Michael Kinney wrote:
> The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE in 
> the MP Services Protocol service StartAllAPs().  Any function used as 
> an EFI_AP_SERVICE must use EFIAPI calling convention.

I think "EFI_AP_SERVICE" should be "EFI_AP_PROCEDURE" here.

> 
> Cc: Jeff Fan <jeff@intel.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 3 ++-  
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)

EFI_AP_PROCEDURE is defined, in "MdePkg/Include/Pi/PiMultiPhase.h", as:

typedef
VOID
(EFIAPI *EFI_AP_PROCEDURE)(
  IN OUT VOID  *Buffer
  );

Let's compare the prototype of CheckFeatureSupported()
[UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h]:

VOID
CheckFeatureSupported (
  VOID
  );

The lack of EFIAPI is just one (I'd say: the smaller) problem; the parameter 
list is incorrect regardless of calling convention. Therefore:

> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> index ec4ec9b..0279f89 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> @@ -1,7 +1,7 @@
>  /** @file
>  Enable SMM profile.
>  
> -Copyright (c) 2012 - 2015, Intel Corporation. All rights 
> reserved.
> +Copyright (c) 2012 - 2016, Intel Corporation. All rights 
> +reserved.
>  This program and the accompanying materials  are licensed and made 
> available under the terms and conditions of the BSD License  which 
> accompanies this distribution.  The full text of the license may be 
> found at @@ -930,6 +930,7 @@ InitSmmProfileInternal (
>  
>  **/
>  VOID
> +EFIAPI
>  CheckFeatureSupported (
>VOID
>)

Here I propose to fix up the parameter list as well,


> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> index 4548467..5cb8d7c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> @@ -1,7 +1,7 @@
>  /** @file
>  SMM profile header file.
>  
> -Copyright (c) 2012 - 2015, Intel Corporation. All rights 
> reserved.
> +Copyright (c) 2012 - 2016, Intel Corporation. All rights 
> +reserved.
>  This program and the accompanying materials  are licensed and made 
> available under the terms and conditions of the BSD License  which 
> accompanies this distribution.  The full text of the license may be 
> found at @@ -97,6 +97,7 @@ PageFaultIdtHandlerSmmProfile (
>  
>  **/
>  VOID
> +EFIAPI
>  CheckFeatureSupported (
>VOID
>);
> 

here too; *plus* drop the (now unnecessary) cast from:

MpServices->StartupAllAPs (
  MpServices,
  (EFI_AP_PROCEDURE) CheckFeatureSupported,
  TRUE,
  NULL,
  0,
  NULL,
  NULL
  );

in CheckProcessorFeature().

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Enable/Restore XD in SMM

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Kinney
Sent: Friday, February 19, 2016 10:36 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Fan, Jeff
Subject: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Enable/Restore XD in SMM

If XD is supported, then SMM enables it.  The non-SMM execution environment can 
choose to enable or disable XD, so the state of XD must be detected in each SMI 
and be enabled/restored.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  | 18 +++---  
UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h |  3 ++-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index 79b7c90..185cb3d 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -1,7 +1,7 @@
 /** @file
 SMM MP service implementation
 
-Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -1019,6 +1019,7 
@@ SmiRendezvous (
   BOOLEAN   BspInProgress;
   UINTN Index;
   UINTN Cr2;
+  BOOLEAN   XdDisableFlag;
 
   //
   // Save Cr2 because Page Fault exception in SMM may override its value @@ 
-1078,9 +1079,14 @@ SmiRendezvous (
 }
 
 //
-// Try to enable NX
+// Try to enable XD
 //
+XdDisableFlag = FALSE;
 if (mXdSupported) {
+  if ((AsmReadMsr64 (MSR_IA32_MISC_ENABLE) & B_XD_DISABLE_BIT) != 0) {
+XdDisableFlag = TRUE;
+AsmMsrAnd64 (MSR_IA32_MISC_ENABLE, ~B_XD_DISABLE_BIT);
+  }
   ActivateXd ();
 }
 
@@ -1152,7 +1158,6 @@ SmiRendezvous (
 // BSP Handler is always called with a ValidSmi == TRUE
 //
 BSPHandler (CpuIndex, mSmmMpSyncData->EffectiveSyncMode);
-
   } else {
 APHandler (CpuIndex, ValidSmi, mSmmMpSyncData->EffectiveSyncMode);
   }
@@ -1165,6 +1170,13 @@ SmiRendezvous (
 //
 while (mSmmMpSyncData->AllCpusInSync) {
   CpuPause ();
+ }
+
+//
+// Restore XD
+//
+if (XdDisableFlag) {
+  AsmMsrOr64 (MSR_IA32_MISC_ENABLE, B_XD_DISABLE_BIT);
 }
   }
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
index 4548467..f91c104 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
@@ -1,7 +1,7 @@
 /** @file
 SMM profile header file.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -21,6 +21,7 @@ 
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 /// MSR Register Index
 ///
 #define MSR_IA32_MISC_ENABLE  0x1A0
+#define   B_XD_DISABLE_BITBIT34
 
 //
 // External functions
--
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v2] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to CheckFeatureSupported()

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Kinney
Sent: Friday, February 19, 2016 9:54 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Laszlo Ersek; Fan, Jeff
Subject: [edk2] [Patch v2] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to 
CheckFeatureSupported()

The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE in the MP 
Services Protocol service StartAllAPs().  Any function used as an 
EFI_AP_PROCEDURE must use EFIAPI calling convention.

Cc: Laszlo Ersek <ler...@redhat.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 9 +  
UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h | 5 +++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index ec4ec9b..9c4f387 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -1,7 +1,7 @@
 /** @file
 Enable SMM profile.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -930,8 +930,9 @@ 
InitSmmProfileInternal (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
-  VOID
+  IN OUT VOID   *Buffer
   )
 {
   UINT32 RegEax;
@@ -1001,7 +1002,7 @@ CheckProcessorFeature (
   //
   // Check if XD and BTS are supported on all processors.
   //
-  CheckFeatureSupported ();
+  CheckFeatureSupported (NULL);
 
   //
   //Check on other processors if BSP supports this @@ -1009,7 +1010,7 @@ 
CheckProcessorFeature (
   if (mXdSupported || mBtsSupported) {
 MpServices->StartupAllAPs (
   MpServices,
-  (EFI_AP_PROCEDURE) CheckFeatureSupported,
+  CheckFeatureSupported,
   TRUE,
   NULL,
   0,
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
index 4548467..d65048e 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
@@ -1,7 +1,7 @@
 /** @file
 SMM profile header file.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -97,8 +97,9 @@ 
PageFaultIdtHandlerSmmProfile (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
-  VOID
+  IN OUT VOID   *Buffer
   );
 
 /**
--
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v2] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to CheckFeatureSupported()

[Fan, Jeff]

Mike,

One more comment. Please add the @param as blow in CheckFeatureSupported()'s 
function header.

  @param[in,out] Buffer  The pointer to private data buffer.

Thanks!
Jeff

-Original Message-
From: Fan, Jeff 
Sent: Friday, February 19, 2016 3:54 PM
To: Michael Kinney; edk2-devel@lists.01.org
Cc: Yao, Jiewen; Laszlo Ersek
Subject: RE: [edk2] [Patch v2] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to 
CheckFeatureSupported()

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Kinney
Sent: Friday, February 19, 2016 9:54 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Laszlo Ersek; Fan, Jeff
Subject: [edk2] [Patch v2] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to 
CheckFeatureSupported()

The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE in the MP 
Services Protocol service StartAllAPs().  Any function used as an 
EFI_AP_PROCEDURE must use EFIAPI calling convention.

Cc: Laszlo Ersek <ler...@redhat.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 9 +  
UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h | 5 +++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index ec4ec9b..9c4f387 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -1,7 +1,7 @@
 /** @file
 Enable SMM profile.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -930,8 +930,9 @@ 
InitSmmProfileInternal (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
-  VOID
+  IN OUT VOID   *Buffer
   )
 {
   UINT32 RegEax;
@@ -1001,7 +1002,7 @@ CheckProcessorFeature (
   //
   // Check if XD and BTS are supported on all processors.
   //
-  CheckFeatureSupported ();
+  CheckFeatureSupported (NULL);
 
   //
   //Check on other processors if BSP supports this @@ -1009,7 +1010,7 @@ 
CheckProcessorFeature (
   if (mXdSupported || mBtsSupported) {
 MpServices->StartupAllAPs (
   MpServices,
-  (EFI_AP_PROCEDURE) CheckFeatureSupported,
+  CheckFeatureSupported,
   TRUE,
   NULL,
   0,
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
index 4548467..d65048e 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
@@ -1,7 +1,7 @@
 /** @file
 SMM profile header file.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -97,8 +97,9 @@ 
PageFaultIdtHandlerSmmProfile (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
-  VOID
+  IN OUT VOID   *Buffer
   );
 
 /**
--
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v2 00/21] UefiCpuPkg/Include: Add MSR include files

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com> for this serial of patches.

-Original Message-
From: Kinney, Michael D 
Sent: Saturday, March 12, 2016 8:09 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff; Yao, Jiewen
Subject: [Patch v2 00/21] UefiCpuPkg/Include: Add MSR include files

Add include files for Architectural MSRs and family specific MSRs described in 
section 35.1 to 35.20 of the
Intel(R) 64 and IA-32 Architectures Software Developer's Manual, Volume 3, 
December 2015, Chapter 35 Model-Specific-Registers (MSR).

New in V2 based on review feedback from Jeff Fan 
=
* Fix spelling errors in comments
* Remove KERNEL_GSBASE from all family specific .h files.  
  These are identical to KERNEL_GS_BASE in ArchitecturalMsr.h
* Remove IA32_TSC_AUX from XeonPhi.h.  
  It is identical to IA32_TSC_AUX in ArchitecturalMsr.h
* Move 5 MSR_BROADWELL_C17_PMON_BOX_STATUS and MSR_BROADWELL_C17_PMON_CRTn
  MSRs from BroadwellMsr.h to HaswellEMsr.h
* PentiumMMsr.h: Change field from Reserved to BTS in
  MSR_PENTIUM_M_IA32_MISC_ENABLE
* SandyBridgeMsr.h: Remove MSR_SANDY_BRIDGE_X2APIC
* Xeon5600Msr.h: Move bitfieds from MSR_XEON_5600_OFFCORE_RSP_1 to
  MSR_XEON_5600_TURBO_RATIO_LIMIT
* XeonDMsr.h: Change Reserved to BTS in MSR_XEON_D_IA32_L3_QOS_MASK_REGISTER

These files can also be pulled and reviewd from:

https://github.com/mdkinney/edk2/tree/Msr_V2

These includes files are not being used by any modules or libraries yet, so 
adding these .h files should not have any impact on any build.  

I have tested that these include files do not cause any build failures when 
used in UefiCPuPkg/Application/Cpuid.

These include files are being added so the defines and REGISTER structures can 
be used clean up IA32/X64 CPU modules and libraries that access MSRs.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>

Michael Kinney (21):
  UefiCpuPkg/Include: Add Architectural MSR include file
  UefiCpuPkg/Include: Add Core 2 MSR include file
  UefiCpuPkg/Include: Add Atom MSR include file
  UefiCpuPkg/Include: Add Silvermont MSR include file
  UefiCpuPkg/Include: Add Nehalem MSR include file
  UefiCpuPkg/Include: Add Xeon 5600 MSR include file
  UefiCpuPkg/Include: Add Xeon E7 MSR include file
  UefiCpuPkg/Include: Add Sandy Bridge MSR include file
  UefiCpuPkg/Include: Add Ivy Bridge MSR include file
  UefiCpuPkg/Include: Add Haswell MSR include file
  UefiCpuPkg/Include: Add Haswell-E MSR include file
  UefiCpuPkg/Include: Add Broadwell MSR include file
  UefiCpuPkg/Include: Add Xeon Processor D MSR include file
  UefiCpuPkg/Include: Add Skylake MSR include file
  UefiCpuPkg/Include: Add Xeon Phi MSR include file
  UefiCpuPkg/Include: Add Pentium 4 MSR include file
  UefiCpuPkg/Include: Add Core Solo/Duo MSR include file
  UefiCpuPkg/Include: Add Pentium M MSR include file
  UefiCpuPkg/Include: Add P6 MSR include file
  UefiCpuPkg/Include: Add Pentium MSR include file
  UefiCpuPkg/Include: Add top level MSR include file

 UefiCpuPkg/Include/Register/ArchitecturalMsr.h   | 5801 +
 UefiCpuPkg/Include/Register/Msr.h|   48 +
 UefiCpuPkg/Include/Register/Msr/AtomMsr.h|  878 +++
 UefiCpuPkg/Include/Register/Msr/BroadwellMsr.h   |  265 +
 UefiCpuPkg/Include/Register/Msr/Core2Msr.h   | 1325 
 UefiCpuPkg/Include/Register/Msr/CoreMsr.h| 1074 
 UefiCpuPkg/Include/Register/Msr/HaswellEMsr.h| 5995 ++
 UefiCpuPkg/Include/Register/Msr/HaswellMsr.h | 2575 
 UefiCpuPkg/Include/Register/Msr/IvyBridgeMsr.h   | 2830 +
 UefiCpuPkg/Include/Register/Msr/NehalemMsr.h | 7196 ++
 UefiCpuPkg/Include/Register/Msr/P6Msr.h  | 1608 +
 UefiCpuPkg/Include/Register/Msr/Pentium4Msr.h| 2550 
 UefiCpuPkg/Include/Register/Msr/PentiumMMsr.h|  643 ++
 UefiCpuPkg/Include/Register/Msr/PentiumMsr.h |  121 +
 UefiCpuPkg/Include/Register/Msr/SandyBridgeMsr.h | 4703 ++  
UefiCpuPkg/Include/Register/Msr/SilvermontMsr.h  | 1468 +
 UefiCpuPkg/Include/Register/Msr/SkylakeMsr.h | 1008 +++
 UefiCpuPkg/Include/Register/Msr/Xeon5600Msr.h|  182 +
 UefiCpuPkg/Include/Register/Msr/XeonDMsr.h   | 1430 +
 UefiCpuPkg/Include/Register/Msr/XeonE7Msr.h  |  254 +
 UefiCpuPkg/Include/Register/Msr/XeonPhiMsr.h | 1426 +
 21 files changed, 43380 insertions(+)
 create mode 100644 UefiCpuPkg/Include/Register/ArchitecturalMsr.h
 create mode 100644 UefiCpuPkg/Include/Register/Msr.h  create mode 100644 
UefiCpuPkg/Include/Register/Msr/AtomMsr.h
 create mode 100644 UefiCpuPkg/Include/Register/Msr/BroadwellMsr.h
 create mode 100644 UefiCpuPkg/Include/Register/Msr/Core2Msr.h
 create mode 100644 UefiCpuPkg/Include/Register/Msr/CoreMsr.h
 create mode 100644 UefiCpuPkg/Include/Register/Msr/Ha

Re: [edk2] [PATCH 1/1] UefiCpuPkg: CpuIo2Dxe: optimize FIFO reads and writes of IO ports

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

VS2013 build pass.

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, April 08, 2016 6:22 PM
To: edk2-devel-01
Cc: Justen, Jordan L; Ni, Ruiyu; Fan, Jeff; Mark
Subject: [PATCH 1/1] UefiCpuPkg: CpuIo2Dxe: optimize FIFO reads and writes of 
IO ports

* Short description:

  The CpuIoServiceRead() and CpuIoServiceWrite() functions transfer data
  between memory and IO ports with individual Io(Read|Write)(8|16|32)
  function calls, each in an appropriately set up loop.

  On the Ia32 and X64 platforms however, FIFO reads and writes can be
  optimized, by coding them in assembly, and delegating the loop to the
  CPU, with the REP prefix.

  On KVM virtualization hosts, this difference has a huge performance
  impact: if the loop is open-coded, then the virtual machine traps to the
  hypervisor on every single UINT8 / UINT16 / UINT32 transfer, whereas
  with the REP prefix, KVM can transfer up to a page of data per VM trap.
  This is especially noticeable with IDE PIO transfers, where all the data
  are squeezed through IO ports.

* Long description:

  The RootBridgeIoIoRW() function in

PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c

  used to have the exact same IO port acces optimization, dating back
  verbatim to commit 1fd376d9792:

PcAtChipsetPkg/PciHostBridgeDxe: Improve KVM FIFO I/O read/write
  performance

  OvmfPkg cloned the "PcAtChipsetPkg/PciHostBridgeDxe" driver (for
  unrelated reasons), and inherited the optimization from PcAtChipsetPkg.

  The "PcAtChipsetPkg/PciHostBridgeDxe" driver was ultimately removed in
  commit 111d79db47:

PcAtChipsetPkg/PciHostBridge: Remove PciHostBridge driver

  and OvmfPkg too was rebased to the new core Pci Host Bridge Driver, in
  commit 4014885ffd:

OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe

  This caused the optimization to go lost. Namely, the
  RootBridgeIoIoRead() and RootBridgeIoIoWrite() functions in the new core
  Pci Host Bridge Driver delegate IO port accesses to
  EFI_CPU_IO2_PROTOCOL. And, in OvmfPkg (and likely most other Ia32 / X64
  edk2 platforms), this protocol is provided by "UefiCpuPkg/CpuIo2Dxe",
  which lacks the optimization.

  Therefore, this patch ports the C source code logic from commit
  1fd376d9792 (see above) to "UefiCpuPkg/CpuIo2Dxe", plus it ports the
  NASM-converted assembly helper functions from OvmfPkg commits
  6026bf460037 and ace1d0517b65:

OvmfPkg PciHostBridgeDxe: Convert Ia32/IoFifo.asm to NASM

OvmfPkg PciHostBridgeDxe: Convert X64/IoFifo.asm to NASM

  In order to support the MSFT and INTEL toolchains as well, the *.asm
  files are ported from OvmfPkg as well, immediately from before the above
  conversion (that is, at 6026bf460037^).

* Notes about the port:

  - The write and read branches from commit 1fd376d9792 are split to the
separate functions CpuIoServiceWrite() and CpuIoServiceRead().

  - The EfiPciWidthUintXX constants are replaced with EfiCpuIoWidthUintXX.

  - The cast expression "(UINTN) Address" is replaced with
"(UINTN)Address" (i.e., no space), because that's how the receiving
functions spell it as well.

  - The labels in the switch statements are unindented by one level, to
match the edk2 coding style (and the rest of UefiCpuPkg) better.

* The first signoff belongs to Jordan, because he authored all of
  1fd376d9792, 6026bf460037 and ace1d0517b65.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
Ref: https://www.redhat.com/archives/vfio-users/2016-April/msg00029.html
Reported-by: Mark <kram...@gmail.com>
Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/10424/focus=10432
Reported-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Mark <kram...@gmail.com>
---

Notes:
v2:
- port *.asm files too, for INTEL and MSFT [Jordan, Jeff]

 UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf|  11 ++
 UefiCpuPkg/CpuIo2Dxe/IoFifo.h | 176 
 UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.c  |  49 ++
 UefiCpuPkg/CpuIo2Dxe/Ia32/IoFifo.asm  | 140   
UefiCpuPkg/CpuIo2Dxe/Ia32/IoFifo.nasm | 136 +++
 UefiCpuPkg/CpuIo2Dxe/X64/IoFifo.asm   | 126 ++
 UefiCpuPkg/CpuIo2Dxe/X64/IoFifo.nasm  | 125 ++
 7 files changed, 763 insertions(+)

diff --git a/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf 
b/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
index 8ef8b3d31cff..8af39ff250c0 100644
--- a/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
+++ b/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
@@ -30,7 +30,18 @@ [Defines]
 [Sources]
   CpuIo2Dxe.c
   CpuIo2Dxe.h
+  IoFifo.h
  

Re: [edk2] [PATCH] UefiCpuPkg: CpuIo2Dxe: optimize FIFO reads and writes of IO ports

[Fan, Jeff]

Laszlo,

Please add .asm file implementation to support MSFT tool chain also, because 
NASM is not required for MSTF tool chain now.
If you cannot verify MSFT build, I could help to verify your patch with .asm 
file.

Jeff
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Friday, April 08, 2016 5:52 AM
To: edk2-devel-01
Cc: Ni, Ruiyu; Justen, Jordan L; Fan, Jeff; Mark
Subject: [edk2] [PATCH] UefiCpuPkg: CpuIo2Dxe: optimize FIFO reads and writes 
of IO ports

* Short description:

  The CpuIoServiceRead() and CpuIoServiceWrite() functions transfer data
  between memory and IO ports with individual Io(Read|Write)(8|16|32)
  function calls, each in an appropriately set up loop.

  On the Ia32 and X64 platforms however, FIFO reads and writes can be
  optimized, by coding them in assembly, and delegating the loop to the
  CPU, with the REP prefix.

  On KVM virtualization hosts, this difference has a huge performance
  impact: if the loop is open-coded, then the virtual machine traps to the
  hypervisor on every single UINT8 / UINT16 / UINT32 transfer, whereas
  with the REP prefix, KVM can transfer up to a page of data per VM trap.
  This is especially noticeable with IDE PIO transfers, where all the data
  are squeezed through IO ports.

* Long description:

  The RootBridgeIoIoRW() function in

PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c

  used to have the exact same IO port acces optimization, dating back
  verbatim to commit 1fd376d9792:

PcAtChipsetPkg/PciHostBridgeDxe: Improve KVM FIFO I/O read/write
  performance

  OvmfPkg cloned the "PcAtChipsetPkg/PciHostBridgeDxe" driver (for
  unrelated reasons), and inherited the optimization from PcAtChipsetPkg.

  The "PcAtChipsetPkg/PciHostBridgeDxe" driver was ultimately removed in
  commit 111d79db47:

PcAtChipsetPkg/PciHostBridge: Remove PciHostBridge driver

  and OvmfPkg too was rebased to the new core Pci Host Bridge Driver, in
  commit 4014885ffd:

OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe

  This caused the optimization to go lost. Namely, the
  RootBridgeIoIoRead() and RootBridgeIoIoWrite() functions in the new core
  Pci Host Bridge Driver delegate IO port accesses to
  EFI_CPU_IO2_PROTOCOL. And, in OvmfPkg (and likely most other Ia32 / X64
  edk2 platforms), this protocol is provided by "UefiCpuPkg/CpuIo2Dxe",
  which lacks the optimization.

  Therefore, this patch ports the C source code logic from commit
  1fd376d9792 (see above) to "UefiCpuPkg/CpuIo2Dxe", plus it ports the
  NASM-converted assembly helper functions from OvmfPkg commits
  6026bf460037 and ace1d0517b65:

OvmfPkg PciHostBridgeDxe: Convert Ia32/IoFifo.asm to NASM

OvmfPkg PciHostBridgeDxe: Convert X64/IoFifo.asm to NASM

* Notes about the port:

  - The write and read branches from commit 1fd376d9792 are split to the
separate functions CpuIoServiceWrite() and CpuIoServiceRead().

  - The EfiPciWidthUintXX constants are replaced with EfiCpuIoWidthUintXX.

  - The cast expression "(UINTN) Address" is replaced with
"(UINTN)Address" (i.e., no space), because that's how the receiving
functions spell it as well.

  - The labels in the switch statements are unindented by one level, to
match the edk2 coding style (and the rest of UefiCpuPkg) better.

* The first signoff belongs to Jordan, because he authored all of
  1fd376d9792, 6026bf460037 and ace1d0517b65.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
Ref: https://www.redhat.com/archives/vfio-users/2016-April/msg00029.html
Reported-by: Mark <kram...@gmail.com>
Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/10424/focus=10432
Reported-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Mark <kram...@gmail.com>
---
 UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf|   7 +
 UefiCpuPkg/CpuIo2Dxe/IoFifo.h | 176 
 UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.c  |  49 ++
 UefiCpuPkg/CpuIo2Dxe/Ia32/IoFifo.nasm | 136 +++  
UefiCpuPkg/CpuIo2Dxe/X64/IoFifo.nasm  | 125 ++
 5 files changed, 493 insertions(+)

diff --git a/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf 
b/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
index 8ef8b3d31cff..be79b1b3b992 100644
--- a/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
+++ b/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
@@ -30,7 +30,14 @@ [Defines]
 [Sources]
   CpuIo2Dxe.c
   CpuIo2Dxe.h
+  IoFifo.h
   
+[Sources.IA32]
+  Ia32/IoFifo.nasm
+
+[Sources.X64]
+  X64/IoFifo.nasm
+
 [Packages]
   MdePkg/MdePkg.dec
 
diff --git a/UefiCpuPkg/CpuIo2Dxe/IoFifo.h b/UefiCpuPkg/CpuIo2Dxe/IoFifo.h new 
file m

Re: [edk2] [Patch] MdePkg/BaseSynchronizationLib: Add spin lock alignment for IA32/x64

[Fan, Jeff]

I removed the non-ASCII character in patch v2.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff Fan
Sent: Tuesday, March 22, 2016 2:53 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D; Gao, Liming
Subject: [edk2] [Patch] MdePkg/BaseSynchronizationLib: Add spin lock alignment 
for IA32/x64

From Intel(R) 64 and IA-32 Architectures Software Developer’s Manual, one lock 
or semaphore is suggested to be present within a cache line. If the processors 
are based on Intel NetBurst microarchitecture, two cache lines are suggested.
This could minimize the bus traffic required to service locks.

Cc: Michael Kinney <michael.d.kin...@intel.com>
Cc: Liming Gao <liming@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff@intel.com>
---
 .../BaseSynchronizationLib.inf |  8 ++-
 .../BaseSynchronizationLibInternals.h  | 14 -
 .../Ia32/InternalGetSpinLockProperties.c   | 60 ++
 .../Ipf/InternalGetSpinLockProperties.c| 29 +++
 .../BaseSynchronizationLib/SynchronizationGcc.c|  2 +-
 .../BaseSynchronizationLib/SynchronizationMsc.c|  2 +-
 6 files changed, 111 insertions(+), 4 deletions(-)  create mode 100644 
MdePkg/Library/BaseSynchronizationLib/Ia32/InternalGetSpinLockProperties.c
 create mode 100644 
MdePkg/Library/BaseSynchronizationLib/Ipf/InternalGetSpinLockProperties.c

diff --git a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf 
b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
index bd1bec3..6930d21 100755
--- a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
+++ b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Base Synchronization Library implementation.
 #
-#  Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2016, Intel Corporation. All rights 
+reserved.
 #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.  #  
#  This program and the accompanying materials @@ -30,6 +30,8 @@
   BaseSynchronizationLibInternals.h
 
 [Sources.IA32]
+  Ia32/InternalGetSpinLockProperties.c
+
   Ia32/InterlockedCompareExchange64.c | MSFT 
   Ia32/InterlockedCompareExchange32.c | MSFT 
   Ia32/InterlockedCompareExchange16.c | MSFT @@ -48,6 +50,8 @@
   SynchronizationGcc.c  | GCC
 
 [Sources.X64]
+  Ia32/InternalGetSpinLockProperties.c
+
   X64/InterlockedCompareExchange64.c | MSFT
   X64/InterlockedCompareExchange32.c | MSFT
   X64/InterlockedCompareExchange16.c | MSFT @@ -68,6 +72,8 @@
   SynchronizationGcc.c  | GCC 
 
 [Sources.IPF]
+  Ipf/InternalGetSpinLockProperties.c
+
   Ipf/Synchronization.c
   Ipf/InterlockedCompareExchange64.s
   Ipf/InterlockedCompareExchange32.s
diff --git 
a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLibInternals.h 
b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLibInternals.h
index 76f7023..9716b92 100644
--- a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLibInternals.h
+++ b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLibIntern
+++ als.h
@@ -1,7 +1,7 @@
 /** @file
   Declaration of internal functions in BaseSynchronizationLib.
 
-  Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2016, Intel Corporation. All rights 
+ reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at @@ -138,4 +138,16 @@ InternalSyncCompareExchange64 (
   IN  UINT64ExchangeValue
   );
 
+/**
+  Internal function to retrieve the architecture specific spin lock 
+alignment
+  requirements for optimal spin lock performance.
+
+  @return The architecture specific spin lock alignment.
+  
+**/
+UINTN
+InternalGetSpinLockProperties (
+  VOID
+  );
+
 #endif
diff --git 
a/MdePkg/Library/BaseSynchronizationLib/Ia32/InternalGetSpinLockProperties.c 
b/MdePkg/Library/BaseSynchronizationLib/Ia32/InternalGetSpinLockProperties.c
new file mode 100644
index 000..49f05fb
--- /dev/null
+++ b/MdePkg/Library/BaseSynchronizationLib/Ia32/InternalGetSpinLockProp
+++ erties.c
@@ -0,0 +1,60 @@
+/** @file
+  Internal function to get spin lock alignment.
+
+  Copyright (c) 2016, Intel Corporation. All rights reserved.  This 
+ program and the accompanying materials  are licensed and made 
+ available under the terms and conditions of the BSD License  which 
+ accompanies this distribution.  The full text of the license may be 
+ found at  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,  
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "BaseSynchronizationL

Re: [edk2] [PATCH 00/35] remove unused but set variables

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Thursday, March 24, 2016 6:37 PM
To: edk2-devel-01
Cc: Ni, Ruiyu; Tian, Feng; Ard Biesheuvel; Wu, Hao A; Justen, Jordan L; Andrew 
Fish; Gao, Liming; Wu, Jiaxin; Yao, Jiewen; Zeng, Star; Kinney, Michael D; Fu, 
Siyuan; Fan, Jeff; Agyeman, Prince
Subject: [edk2] [PATCH 00/35] remove unused but set variables

This series removes unused but set variables from edk2, so that the source 
builds after Ard's patch (the last one in this series) lets 
-Wunused-but-set-variables take effect for GCC DEBUG builds.

I used the following method for locating these warnings:
* "-Werror" was temporarily removed;
* I rounded up the DSC files in the tree;
* I built each DSC file for:
  { RELEASE, DEBUG } x { IA32, X64, ARM, AARCH64 };
* some platform DSCs obviously don't build for all four arches above, I
  ignored those errors;
* some platforms I couldn't build at all, I ignored those too;
* for the rest (i.e., when a given DSC built for at least some
  platforms), I collected the warnings from the logs, across all the
  arches that the DSC did build for, and I silenced them.

Maintainers are invited to exert caution while reviewing the patches.
Namely, in a few cases, the silencing is almost certainly wrong, and should be 
replaced with proper error checking. These are the cases when a Status variable 
is set from a function call, but then never checked. I didn't try to handle 
these errors myself; I just removed the Status variable.

Obviously, this method does not change behavior, but the gcc warning in this 
case signals something much worse than a forgotten variable: lack of error 
handling. So, dear maintainers, if you recognize this pattern on your turf, 
please indicate in your reviews that you are going to post a real error 
handling fix for that warning.

The list of DSC's I could build (at least for some architectures):

  AppPkg/AppPkg.dsc
  ArmPkg/ArmPkg.dsc
  ArmVirtPkg/ArmVirtQemu.dsc
  ArmVirtPkg/ArmVirtQemuKernel.dsc
  ArmVirtPkg/ArmVirtXen.dsc
  BeagleBoardPkg/BeagleBoardPkg.dsc
  CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
  CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
  CryptoPkg/CryptoPkg.dsc
  DuetPkg/DuetPkgIa32.dsc
  DuetPkg/DuetPkgX64.dsc
  EdkCompatibilityPkg/EdkCompatibilityPkg.dsc
  EmulatorPkg/EmulatorPkg.dsc
  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc
  IntelFrameworkPkg/IntelFrameworkPkg.dsc
  IntelFspPkg/IntelFspPkg.dsc
  IntelFspWrapperPkg/IntelFspWrapperPkg.dsc
  MdeModulePkg/MdeModulePkg.dsc
  MdePkg/MdePkg.dsc
  NetworkPkg/NetworkPkg.dsc
  OptionRomPkg/OptionRomPkg.dsc
  OvmfPkg/OvmfPkgIa32.dsc
  OvmfPkg/OvmfPkgIa32X64.dsc
  OvmfPkg/OvmfPkgX64.dsc
  PcAtChipsetPkg/PcAtChipsetPkg.dsc
  PerformancePkg/PerformancePkg.dsc
  QuarkSocPkg/QuarkSocPkg.dsc
  SecurityPkg/SecurityPkg.dsc
  ShellPkg/ShellPkg.dsc
  SourceLevelDebugPkg/SourceLevelDebugPkg.dsc
  StdLib/StdLib.dsc
  UefiCpuPkg/UefiCpuPkg.dsc

(Side note: CryptoPkg implies OpenSSL-1.0.2g.)

The list of DSC's that wouldn't build for me at all (on Linux, with
GCC48):

  EmbeddedPkg/EmbeddedPkg.dsc
  Nt32Pkg/Nt32Pkg.dsc
  Omap35xxPkg/Omap35xxPkg.dsc
  QuarkPlatformPkg/Quark.dsc
  QuarkPlatformPkg/QuarkMin.dsc
  Vlv2TbltDevicePkg/PlatformPkgConfig.dsc
  Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
  Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
  Vlv2TbltDevicePkg/PlatformPkgX64.dsc

Fixing any possible warnings in these packages is left as an exercise to their 
respective maintainers.

Public branch:
<https://github.com/lersek/edk2/commits/warn_unused_but_set>.

Cc: Andrew Fish <af...@apple.com>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: Feng Tian <feng.t...@intel.com>
Cc: Hao Wu <hao.a...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Jiaxin Wu <jiaxin...@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Kelly Steele <kelly.ste...@intel.com>
Cc: Liming Gao <liming@intel.com>
Cc: Maurice Ma <maurice...@intel.com>
Cc: Michael D Kinney <michael.d.kin...@intel.com>
Cc: Michael Kinney <michael.d.kin...@intel.com>
Cc: Prince Agyeman <prince.agye...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Siyuan Fu <siyuan...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Yonghong Zhu <yonghong@intel.com>

Thanks
Laszlo

Ard Biesheuvel (3):
  MdeModulePkg/PciHostBridgeDxe: remove unused but set variables
  UefiCpuPkg/MtrrLib: remove unused but set variable
  BaseTools/GCC: set -Wno-unused-but-set-variables only on RELEASE
builds

Laszlo Ersek (32):
  CorebootPayloadPkg: FbGop: remove set but unused variables
  CorebootPayloadPkg: PlatformBdsLib: remove set but unused variables
  EdkCompatibilityPkg: UefiEfiIfrSupportLib: remove set but not used
variables
  EdkCompatibili

Re: [edk2] [Patch] UefiCpuPkg/CpuMpPei: APs needn't to search microcode

[Fan, Jeff]

Please skip this patch. I need to refine this solution. 

Thanks!
Jeff

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff Fan
Sent: Wednesday, March 02, 2016 10:10 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D; Tian, Feng
Subject: [edk2] [Patch] UefiCpuPkg/CpuMpPei: APs needn't to search microcode

To improve performance, BSP will save the latest microcode information during 
searching the update microcode from microcode region. Then, APs needn't to 
search microcode and just make use of the saved latest microcode information.

Cc: Feng Tian <feng.t...@intel.com>
Cc: Michael Kinney <michael.d.kin...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff@intel.com>
---
 UefiCpuPkg/CpuMpPei/CpuMpPei.c  |   7 +-
 UefiCpuPkg/CpuMpPei/CpuMpPei.h  |   3 +-
 UefiCpuPkg/CpuMpPei/Microcode.c | 201 
 UefiCpuPkg/CpuMpPei/Microcode.h |  10 +-
 4 files changed, 109 insertions(+), 112 deletions(-)

diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c b/UefiCpuPkg/CpuMpPei/CpuMpPei.c 
index 950d61c..b1a0cf7 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
@@ -1,7 +1,7 @@
 /** @file
   CPU PEI Module installs CPU Multiple Processor PPI.
 
-  Copyright (c) 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 2016, Intel Corporation. All rights 
+ reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at @@ -302,7 +302,7 @@ ApCFunction (
   // Sync BSP's Mtrr table to all wakeup APs and load microcode on APs.
   //
   MtrrSetAllMtrrs (>MtrrTable);
-  MicrocodeDetect ();
+  MicrocodeDetect (>MicrocodeInfo);
   PeiCpuMpData->CpuData[ProcessorNumber].State = CpuStateIdle;
 } else {
   //
@@ -596,7 +596,7 @@ CountProcessorNumber (
   //
   // Load Microcode on BSP
   //
-  MicrocodeDetect ();
+  MicrocodeDetect (>MicrocodeInfo);
   //
   // Store BSP's MTRR setting
   //
@@ -716,6 +716,7 @@ PrepareAPStartupVector (
   PeiCpuMpData->CpuData[0].ApicId= GetInitialApicId ();
   PeiCpuMpData->CpuData[0].Health.Uint32 = 0;
   PeiCpuMpData->EndOfPeiFlag = FALSE;
+  PeiCpuMpData->MicrocodeInfo.Searched   = FALSE;
   InitializeSpinLock(>MpLock);
   SaveVolatileRegisters (>CpuData[0].VolatileRegisters);
   CopyMem (>AddressMap, , sizeof 
(MP_ASSEMBLY_ADDRESS_MAP)); diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.h 
b/UefiCpuPkg/CpuMpPei/CpuMpPei.h index 7c8a218..c73632a 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
@@ -1,7 +1,7 @@
 /** @file
   Definitions to install Multiple Processor PPI.
 
-  Copyright (c) 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 2016, Intel Corporation. All rights 
+ reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at @@ -161,6 +161,7 @@ struct _PEI_CPU_MP_DATA {
   UINTN  ApFunction;
   UINTN  ApFunctionArgument;
   volatile UINT32FinishedCount;
+  MICROCODE_INFO MicrocodeInfo;
   BOOLEANEndOfPeiFlag;
   BOOLEANInitFlag;
   BOOLEANX2ApicEnable;
diff --git a/UefiCpuPkg/CpuMpPei/Microcode.c b/UefiCpuPkg/CpuMpPei/Microcode.c 
index 35d0387..919cc7f 100644
--- a/UefiCpuPkg/CpuMpPei/Microcode.c
+++ b/UefiCpuPkg/CpuMpPei/Microcode.c
@@ -36,10 +36,11 @@ GetCurrentMicrocodeSignature (
 /**
   Detect whether specified processor can find matching microcode patch and 
load it.
 
+  @param[in]  MicrocodeInfo  Pointer to Microcode information
 **/
 VOID
 MicrocodeDetect (
-  VOID
+  IN MICROCODE_INFO  *MicrocodeInfo
   )
 {
   UINT64  MicrocodePatchAddress;
@@ -53,14 +54,10 @@ MicrocodeDetect (
   UINTN   Index;
   UINT8   PlatformId;
   UINT32  RegEax;
-  UINT32  LatestRevision;
   UINTN   TotalSize;
   UINT32  CheckSum32;
   BOOLEAN CorrectMicrocode;
-  INT32   CurrentSignature;
-  MICROCODE_INFO  MicrocodeInfo;
 
-  ZeroMem (, sizeof (MICROCODE_INFO));
   MicrocodePatchAddress= PcdGet64 (PcdCpuMicrocodePatchAddress);
   MicrocodePatchRegionSize = PcdGet64 (PcdCpuMicrocodePatchRegionSize);
   if (MicrocodePatchRegionSize == 0) {
@@ -70,134 +67,132 @@ MicrocodeDete

Re: [edk2] [PATCH V2] MdePkg Cper.h: Add missing structure for 'Processor Error Record'

[Fan, Jeff]

Reviewed-off-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Wu, Hao A 
Sent: Tuesday, April 05, 2016 2:55 PM
To: edk2-devel@lists.01.org; Fan, Jeff; Gao, Liming; Kinney, Michael D
Cc: Wu, Hao A
Subject: [PATCH V2] MdePkg Cper.h: Add missing structure for 'Processor Error 
Record'

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a...@intel.com>
---
 MdePkg/Include/Guid/Cper.h | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Guid/Cper.h b/MdePkg/Include/Guid/Cper.h index 
d6223df..88e3a58 100644
--- a/MdePkg/Include/Guid/Cper.h
+++ b/MdePkg/Include/Guid/Cper.h
@@ -1,7 +1,7 @@
 /** @file
   GUIDs and definitions used for Common Platform Error Record.
 
-  Copyright (c) 2011 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2011 - 2016, Intel Corporation. All rights 
+ reserved.
   (C) Copyright 2016 Hewlett Packard Enterprise Development LP
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License @@ -347,6 +347,23 @@ typedef struct {  ///@}
 
 ///
+/// The validation bit mask indicates which fields in the IA32/X64 
+Processor /// Error Record structure are valid.
+///@{
+#define EFI_IA32_X64_PROCESSOR_ERROR_APIC_ID_VALID BIT0
+#define EFI_IA32_X64_PROCESSOR_ERROR_CPU_ID_INFO_VALID BIT1
+///@}
+
+///
+/// IA32/X64 Processor Error Record
+///
+typedef struct {
+  UINT64 ValidFields;
+  UINT64 ApicId;
+  UINT8  CpuIdInfo[48];
+} EFI_IA32_X64_PROCESSOR_ERROR_RECORD;
+
+///
 /// The validation bit mask indicates which fields in the Cache Check 
structure  /// are valid.
 ///@{
--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdeModulePkg/PciBus: Should reserve enough bus number for HPC

[Fan, Jeff]

Reviewed-off-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Ni, Ruiyu 
Sent: Wednesday, March 23, 2016 2:16 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Fan, Jeff
Subject: [Patch] MdeModulePkg/PciBus: Should reserve enough bus number for HPC

When there is no bridge before the HPC (hot plug controller), the issue cannot 
be seen.
But when there are bridges before the HPC, the PciBus will only use the value 
(=  + ) as the sub-ordinary bus number for 
HPC.
The correct sub-ordinary bus number should be:
 + (by earlier bridges) + 
.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
index 12647be..f3407bc 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
@@ -1,7 +1,7 @@
 /** @file
   Internal library implementation for PCI Bus module.
 
-Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
 (C) Copyright 2015 Hewlett Packard Enterprise Development LP  This program 
and the accompanying materials  are licensed and made available under the terms 
and conditions of the BSD License @@ -1232,7 +1232,7 @@ PciScanBus (
 //
 // Reserve the larger one between the actual occupied bus number 
and padded bus number
 //
-Status = PciAllocateBusNumber (PciDevice, StartBusNumber, (UINT8) 
(BusRange), );
+Status = PciAllocateBusNumber (PciDevice, SecondBus, 
+ (UINT8) (BusRange), );
 if (EFI_ERROR (Status)) {
   return Status;
 }
--
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question about SmmProfile logic

[Fan, Jeff]

Thanks your report. This is a bug.

We will send the patch to fix it soon. Moreover, PEBS feature is not required 
for SmmProfile and only BTS feature support is enough.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Shifflett, Joseph
Sent: Wednesday, April 27, 2016 12:59 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Question about SmmProfile logic

I have a question about the logic of this code here:

https://svn.code.sf.net/p/edk2/code/trunk/edk2/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c

>From Line 958:

  if (mBtsSupported) {
AsmCpuid (CPUID_VERSION_INFO, NULL, NULL, NULL, );
if ((RegEdx & CPUID1_EDX_BTS_AVAILABLE) != 0) {
  //
  // Per IA32 manuals:
  // When CPUID.1:EDX[21] is set, the following BTS facilities are 
available:
  // 1. The BTS_UNAVAILABLE flag in the IA32_MISC_ENABLE MSR indicates the
  //availability of the BTS facilities, including the ability to set 
the BTS and
  //BTINT bits in the MSR_DEBUGCTLA MSR.
  // 2. The IA32_DS_AREA MSR can be programmed to point to the DS save area.
  //
  if ((AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 11, 11) == 0) &&
  (AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 12, 12) == 0)) {
//
// BTS facilities is supported.
//
mBtsSupported = FALSE;
  }
}
  }


According to Volume 3 of the Intel 64 and IA-32 Architectures Software 
Developer's Manual 
(http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf),
 bits 11 and 12 of MSR _01A0 indicate BTS and PEBS are available and 
supported when the bits are cleared to 0.  I believe the correct code should 
be: 


if ((AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 11, 11) != 0) ||
  (AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 12, 12) != 0)) {
//
// BTS facilities are disabled.
//
mBtsSupported = FALSE;
  }


Please let me know if I am misreading this code block.  I can create a patch if 
appropriate. 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V2 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Add SMRR PhysBase/PhysMask fields check

[Fan, Jeff]

Mike,

We could use SmmCpuFeaturesInitializeProcessor ()'s input parameter "IsMonarch" 
for BSP identification instead of (ProcessorInfo->StatusFlag & 
PROCESSOR_AS_BSP_BIT) to simply the code.

Reviewed-by: Jeff Fan <jeff@intel.com>

Jeff
-Original Message-
From: Kinney, Michael D 
Sent: Wednesday, May 18, 2016 3:08 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff; Yao, Jiewen; Tian, Feng
Subject: [Patch V2 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Add SMRR 
PhysBase/PhysMask fields check

SMRR range size and alignment should follow the rules like MTRR:
a. The minimum range size is 4 KBytes and the base address of the
   range must be on at least a 4-KByte boundary.
b. For ranges greater than 4 KBytes, each range must be of length
   2^n and its base address must be aligned on a 2^n boundary, where
   n is a value equal to or greater than 12. The base-address
   alignment value cannot be less than its length.
Thus, it could meet "Address_Within_Range AND PhysMask = PhysBase AND PhysMask".

Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Cc: Feng Tian <feng.t...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index 3e480e1..f525926 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -1,7 +1,7 @@
 /** @file
 The CPU specific programming for PiSmmCpuDxeSmm module.
 
-Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -245,6 +245,23 
@@ SmmCpuFeaturesInitializeProcessor (
   // is protected and the normal mode code execution will fail.
   //
   if (mSmrrSupported) {
+//
+// SMRR size cannot be less than 4-KBytes
+// SMRR size must be of length 2^n
+// SMRR base alignment cannot be less than SMRR length
+//
+if ((CpuHotPlugData->SmrrSize < SIZE_4KB) ||
+(CpuHotPlugData->SmrrSize != GetPowerOfTwo32 
(CpuHotPlugData->SmrrSize)) ||
+((CpuHotPlugData->SmrrBase & ~(CpuHotPlugData->SmrrSize - 1)) != 
CpuHotPlugData->SmrrBase)) {
+  //
+  // Print message if CPU is BSP
+  //
+  if ((ProcessorInfo->StatusFlag & PROCESSOR_AS_BSP_BIT) != 0) {
+DEBUG ((EFI_D_ERROR, "SMM Base/Size does not meet alignment/size 
requirement!\n"));
+  }
+  CpuDeadLoop ();
+}
+
 AsmWriteMsr64 (mSmrrPhysBaseMsr, CpuHotPlugData->SmrrBase | 
MTRR_CACHE_WRITE_BACK);
 AsmWriteMsr64 (mSmrrPhysMaskMsr, (~(CpuHotPlugData->SmrrSize - 1) & 
EFI_MSR_SMRR_MASK));
 mSmrrEnabled[CpuIndex] = FALSE;
--
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V2 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Add SMRR PhysBase/PhysMask fields check

[Fan, Jeff]

Mike,

I tested this patch and found DEBUG() cannot be printed as expected if SMM 
Base/Mask values do not meet SDM requirement.

The reason is that PiSmmCpuDxeSmm driver will do SMM relocation on Aps firstly 
and then do SMM relocation on BSP at last.
That means Aps will check SMM Base/Mask firstly and run into CpuDeadLoop().  

Because PiSmmCpuDxeSmm will so SMM relocation on Aps one by one in blocking 
mode, we could remove BSP checking and let the first running AP print the DEBUG 
message.

Thanks!
Jeff
-Original Message-
From: Kinney, Michael D 
Sent: Wednesday, May 18, 2016 3:08 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff; Yao, Jiewen; Tian, Feng
Subject: [Patch V2 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Add SMRR 
PhysBase/PhysMask fields check

SMRR range size and alignment should follow the rules like MTRR:
a. The minimum range size is 4 KBytes and the base address of the
   range must be on at least a 4-KByte boundary.
b. For ranges greater than 4 KBytes, each range must be of length
   2^n and its base address must be aligned on a 2^n boundary, where
   n is a value equal to or greater than 12. The base-address
   alignment value cannot be less than its length.
Thus, it could meet "Address_Within_Range AND PhysMask = PhysBase AND PhysMask".

Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Cc: Feng Tian <feng.t...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index 3e480e1..f525926 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -1,7 +1,7 @@
 /** @file
 The CPU specific programming for PiSmmCpuDxeSmm module.
 
-Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -245,6 +245,23 
@@ SmmCpuFeaturesInitializeProcessor (
   // is protected and the normal mode code execution will fail.
   //
   if (mSmrrSupported) {
+//
+// SMRR size cannot be less than 4-KBytes
+// SMRR size must be of length 2^n
+// SMRR base alignment cannot be less than SMRR length
+//
+if ((CpuHotPlugData->SmrrSize < SIZE_4KB) ||
+(CpuHotPlugData->SmrrSize != GetPowerOfTwo32 
(CpuHotPlugData->SmrrSize)) ||
+((CpuHotPlugData->SmrrBase & ~(CpuHotPlugData->SmrrSize - 1)) != 
CpuHotPlugData->SmrrBase)) {
+  //
+  // Print message if CPU is BSP
+  //
+  if ((ProcessorInfo->StatusFlag & PROCESSOR_AS_BSP_BIT) != 0) {
+DEBUG ((EFI_D_ERROR, "SMM Base/Size does not meet alignment/size 
requirement!\n"));
+  }
+  CpuDeadLoop ();
+}
+
 AsmWriteMsr64 (mSmrrPhysBaseMsr, CpuHotPlugData->SmrrBase | 
MTRR_CACHE_WRITE_BACK);
 AsmWriteMsr64 (mSmrrPhysMaskMsr, (~(CpuHotPlugData->SmrrSize - 1) & 
EFI_MSR_SMRR_MASK));
 mSmrrEnabled[CpuIndex] = FALSE;
--
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V3 2/2] QuarkSocPkg/SmmCpuFeaturesLib: Add SMRR PhysBase/PhysMask fields check

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Kinney, Michael D 
Sent: Thursday, May 19, 2016 5:19 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff; Yao, Jiewen; Tian, Feng
Subject: [Patch V3 2/2] QuarkSocPkg/SmmCpuFeaturesLib: Add SMRR 
PhysBase/PhysMask fields check

SMRR range size and alignment should follow the rules like MTRR:
a. The minimum range size is 4 KBytes and the base address of the
   range must be on at least a 4-KByte boundary.
b. For ranges greater than 4 KBytes, each range must be of length
   2^n and its base address must be aligned on a 2^n boundary, where
   n is a value equal to or greater than 12. The base-address
   alignment value cannot be less than its length.
Thus, it could meet "Address_Within_Range AND PhysMask = PhysBase AND PhysMask".

Cc: Jeff Fan <jeff@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Cc: Feng Tian <feng.t...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
---
 .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c| 16 +++-
 .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf  |  4 +++-
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git 
a/QuarkSocPkg/QuarkNorthCluster/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/QuarkSocPkg/QuarkNorthCluster/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index 6c46645..54eeac6 100644
--- 
a/QuarkSocPkg/QuarkNorthCluster/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/QuarkSocPkg/QuarkNorthCluster/Library/SmmCpuFeaturesLib/SmmCpuFeat
+++ uresLib.c
@@ -1,7 +1,7 @@
 /** @file
 The Quark CPU specific programming for PiSmmCpuDxeSmm module.
 
-Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -15,6 +15,8 @@ 
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #define  EFI_MSR_SMRR_PHYS_MASK_VALID  BIT11
@@ -62,6 +64,18 @@ SmmCpuFeaturesInitializeProcessor (
   CpuState->x86.SMBASE = CpuHotPlugData->SmBase[CpuIndex];
 
   //
+  // SMRR size cannot be less than 4-KBytes  // SMRR size must be of 
+ length 2^n  // SMRR base alignment cannot be less than SMRR length  //  
+ if ((CpuHotPlugData->SmrrSize < SIZE_4KB) ||
+  (CpuHotPlugData->SmrrSize != GetPowerOfTwo32 (CpuHotPlugData->SmrrSize)) 
||
+  ((CpuHotPlugData->SmrrBase & ~(CpuHotPlugData->SmrrSize - 1)) != 
CpuHotPlugData->SmrrBase)) {
+DEBUG ((EFI_D_ERROR, "SMM Base/Size does not meet alignment/size 
requirement!\n"));
+CpuDeadLoop ();
+  }
+
+  //
   // Use QNC to initialize SMRR on Quark
   //
   QNCPortWrite(QUARK_NC_HOST_BRIDGE_SB_PORT_ID, 
QUARK_NC_HOST_BRIDGE_IA32_MTRR_SMRR_PHYSBASE, CpuHotPlugData->SmrrBase); diff 
--git 
a/QuarkSocPkg/QuarkNorthCluster/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
b/QuarkSocPkg/QuarkNorthCluster/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
index 473ece0..267ac84 100644
--- 
a/QuarkSocPkg/QuarkNorthCluster/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+++ b/QuarkSocPkg/QuarkNorthCluster/Library/SmmCpuFeaturesLib/SmmCpuFeat
+++ uresLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  The CPU specific programming for PiSmmCpuDxeSmm module.
 #
-#  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+#  Copyright (c) 2009 - 2016, Intel Corporation. All rights 
+reserved.
 #  This program and the accompanying materials  #  are licensed and made 
available under the terms and conditions of the BSD License  #  which 
accompanies this distribution.  The full text of the license may be found at @@ 
-30,5 +30,7 @@
   SmmCpuFeaturesLib.c
 
 [LibraryClasses]
+  BaseLib
+  DebugLib
   QNCAccessLib
 
--
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 0/4] MdeModulePkg/PciBus Do not improperly degrade resource

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Tuesday, May 17, 2016 10:04 AM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu
Subject: [edk2] [Patch 0/4] MdeModulePkg/PciBus Do not improperly degrade 
resource

The patch serials refined the PciBus code and adds a new feature following PI 
spec 1.4a to not improperly degrade resource.

Ruiyu Ni (4):
  MdeModulePkg/PciBus: use better name for local variables.
  MdeModulePkg/PciBus: Remove unused fields in PCI_BAR
  MdeModulePkg/PciBus: Use shorter global variable name
  MdeModulePkg/PciBus: do not improperly degrade resource

 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c|  6 +--
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h|  5 +-
 .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c   | 58 +-
 .../Bus/Pci/PciBusDxe/PciResourceSupport.c | 26 ++
 4 files changed, 65 insertions(+), 30 deletions(-)

--
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v3 02/40] UefiCpuPkg/MpInitLib: Add microcode definitions defined in IA32 SDM

[Fan, Jeff]

Laszlo,

Good catch on #1

For #2, #pack(1), the structure in this patch should have no padding data 
between each fields. But I agree to add #pack(1) to make it more clear.

Thanks!
Jeff
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Monday, July 25, 2016 9:11 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Tian, Feng
Subject: Re: [edk2] [Patch v3 02/40] UefiCpuPkg/MpInitLib: Add microcode 
definitions defined in IA32 SDM

On 07/25/16 04:52, Jeff Fan wrote:
> Add microcode definitions defined in Intel(R) 64 and IA-32 
> Architectures Software Developer's Manual Volume 3A, Section 9.11.
> 
> v3:
>   1. Update SDM date to June, 2016
>   2. Mention BCD format in CPU_MICROCODE_DATE
>   3. Rename ProcessorChecksum to Checksum to match SDM.
> 
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Giri P Mudusuru <giri.p.mudus...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> ---
>  UefiCpuPkg/Include/Register/Microcode.h | 196 
> 
>  1 file changed, 196 insertions(+)
>  create mode 100644 UefiCpuPkg/Include/Register/Microcode.h
> 
> diff --git a/UefiCpuPkg/Include/Register/Microcode.h 
> b/UefiCpuPkg/Include/Register/Microcode.h
> new file mode 100644
> index 000..1f6cd47
> --- /dev/null
> +++ b/UefiCpuPkg/Include/Register/Microcode.h
> @@ -0,0 +1,196 @@
> +/** @file
> +  Microcode Definitions.
> +
> +  Microcode Definitions based on contents of the
> +  Intel(R) 64 and IA-32 Architectures Software Developer's Manual
> +Volume 3A, Section 9.11  Microcode Definitions
> +
> +  Copyright (c) 2016, Intel Corporation. All rights reserved.  
> + This program and the accompanying materials  are licensed and made 
> + available under the terms and conditions of the BSD License  which 
> + accompanies this distribution.  The full text of the license may be 
> + found at  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" 
> + BASIS,  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS 
> OR IMPLIED.
> +
> +  @par Specification Reference:
> +  Intel(R) 64 and IA-32 Architectures Software Developer's Manual, 
> + Volume 3A,  June 2016, Chapter 9 Processor Management and Initialization, 
> Section 9-11.
> +
> +**/
> +
> +#ifndef __MICROCODE_H__
> +#define __MICROCODE_H__
> +
> +///
> +/// CPU Microcode Date in BCD format
> +///
> +typedef union {
> +  struct {
> +UINT32   Year:16;
> +UINT32   Day:8;
> +UINT32   Month:8;
> +  } Bits;
> +  UINT32 Uint32;
> +} CPU_MICROCODE_DATE;
> +
> +///
> +/// CPU Microcode Processor Signature format /// typedef union {
> +  struct {
> +UINT32   Stepping:4;
> +UINT32   Model:4;
> +UINT32   Family:4;
> +UINT32   Type:2;
> +UINT32   Reserved1:2;
> +UINT32   ExtendedModel:4;
> +UINT32   ExtendedFamily:8;
> +UINT32   Reserved2:4;
> +  } Bits;
> +  UINT32 Uint32;
> +} CPU_MICROCODE_PROCESSOR_SIGNATURE;
> +
> +///
> +/// Microcode Update Format definition /// typedef struct {
> +  ///
> +  /// Version number of the update header
> +  ///
> +  UINT32HeaderVersion;
> +  ///
> +  /// Unique version number for the update, the basis for the update
> +  /// signature provided by the processor to indicate the current 
> +update
> +  /// functioning within the processor. Used by the BIOS to 
> +authenticate
> +  /// the update and verify that the processor loads successfully. 
> +The
> +  /// value in this field cannot be used for processor stepping 
> +identification
> +  /// alone. This is a signed 32-bit number.
> +  ///
> +  UINT32UpdateRevision;
> +  ///
> +  /// Date of the update creation in binary format: mmdd (e.g.
> +  /// 07/18/98 is 07181998H).
> +  ///
> +  CPU_MICROCODE_DATEDate;
> +  ///
> +  /// Extended family, extended model, type, family, model, and 
> +stepping
> +  /// of processor that requires this particular update revision 
> +(e.g.,
> +  /// 0650H). Each microcode update is designed specifically for 
> +a
> +  /// given extended family, extended model, type, family, model, and
> +  /// stepping of the processor.
> +  /// The BIOS uses the processor signature field in conjunction with 
> +the
> +  /// CPUID instruction to determine whether or not an update is
> +  /// appropriate to load on a processor. The information encoded 
> +within
&g

Re: [edk2] [Patch v3 05/40] UefiCpuPkg/MpInitLib: Add two instances PeiMpInitLib and DxeMpInitLib

[Fan, Jeff]

Laszlo,

I added my comments after [Jeff] for your each comment.

Thanks!
Jeff
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Monday, July 25, 2016 10:27 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Tian, Feng
Subject: Re: [edk2] [Patch v3 05/40] UefiCpuPkg/MpInitLib: Add two instances 
PeiMpInitLib and DxeMpInitLib

On 07/25/16 04:52, Jeff Fan wrote:
> Add two MP Initialize Library instances PeiMpInitLib.inf and 
> DxeMpInitLib.inf with NULL implementation.
> 
> v3:
>   1. Rename MpInitLibSwitchBsp to MpInitLibSwitchBSP to match PI spec
> 
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Giri P Mudusuru <giri.p.mudus...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> Reviewed-by: Giri P Mudusuru <giri.p.mudus...@intel.com>
> ---
>  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf |  61 ++  
> UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.uni |  22 +++
>  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   | 266 +
>  UefiCpuPkg/Library/MpInitLib/MpLib.c  | 119 
>  UefiCpuPkg/Library/MpInitLib/MpLib.h  |  40 
>  UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf |  61 ++  
> UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.uni |  22 +++
>  UefiCpuPkg/Library/MpInitLib/PeiMpLib.c   | 269 
> ++
>  UefiCpuPkg/UefiCpuPkg.dsc |   3 +-
>  9 files changed, 862 insertions(+), 1 deletion(-)  create mode 100644 
> UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>  create mode 100644 UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.uni
>  create mode 100644 UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
>  create mode 100644 UefiCpuPkg/Library/MpInitLib/MpLib.c
>  create mode 100644 UefiCpuPkg/Library/MpInitLib/MpLib.h
>  create mode 100644 UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
>  create mode 100644 UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.uni
>  create mode 100644 UefiCpuPkg/Library/MpInitLib/PeiMpLib.c

(1) A Null implementation that does not fulfill the promises of the lib class 
interfaces should not invariably return EFI_SUCCESS in my opinion.
Instead, the MpInitLibInitialize() function should return EFI_UNSUPPORTED, and 
all other APIs should return EFI_NOT_READY.

I realize this is purely cosmetic as the implementation will change in the rest 
of the series.
[Jeff] Agree to use EFI_UNSUPPORTED.

(2) I see that some, but not all, of the APIs are kept in the common
(shared) code, while the rest is specialized to PEI vs. DXE. I understand that 
this split lays the foundation for the future implementation, but it should be 
documented in the commit message -- in particular it should be announced in 
this patch *why* the functions are distributed like this.
[Jeff] Agree to add comments in commit log to make a declaration on it.

(3) Once the comment / naming issues are fixed in the library class header file 
that I mentioned earlier, this patch should be adapted.

(In fact I wouldn't mind if these library instances omitted those huge comments 
altogether. I know it wouldn't conform to the edk2 coding style, but comment 
blocks of *this* size just make it harder to read the code; and the mindless 
copying just perpetuates errors in the comments.
This patch adds 800+ lines of code, without any functionality at all.)
[Jeff] I think I could simply the functions header size for those internal 
functions. But for external APIs, I prefer to keep the comments.

I think (2) is quite important. The other two comments are not crazy important.

Thanks
Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v3 03/40] UefiCpuPkg/CpuS3DataDxe: Move StartupVector allocation to EndOfDxe()

[Fan, Jeff]

Laszlo,

Agree, I will update it in v4. 

Jeff
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Monday, July 25, 2016 9:24 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Tian, Feng
Subject: Re: [edk2] [Patch v3 03/40] UefiCpuPkg/CpuS3DataDxe: Move 
StartupVector allocation to EndOfDxe()

On 07/25/16 04:52, Jeff Fan wrote:
> Currently, we will allocate StartupVector buffer under 1MB at entry 
> point function. But some modules may allocate some hard code address under 
> 1MB.
> For example, LegacyBiosDxe driver tries to manage some legacy range 
> under 640KB.
> 
> To avoid the conflicts, we move StartupVector buffer allocation to End 
> Of DXE event callback function.
> 
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Giri P Mudusuru <giri.p.mudus...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> Reviewed-by: Giri P Mudusuru <giri.p.mudus...@intel.com>
> ---
>  UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c  | 39 
> ++--
>  UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf |  2 +-
>  2 files changed, 23 insertions(+), 18 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c 
> b/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> index 9fb47dc..9e76cae 100644
> --- a/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> +++ b/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> @@ -9,7 +9,7 @@ number of CPUs reported by the MP Services Protocol, 
> so this module does not  support hot plug CPUs.  This module can be 
> copied into a CPU specific package  and customized if these additional 
> features are required.
>  
> -Copyright (c) 2013 - 2015, Intel Corporation. All rights 
> reserved.
> +Copyright (c) 2013 - 2016, Intel Corporation. All rights 
> +reserved.
>  Copyright (c) 2015, Red Hat, Inc.
>  
>  This program and the accompanying materials @@ -45,6 +45,8 @@ typedef 
> struct {
>IA32_DESCRIPTOR   IdtrProfile;
>  } ACPI_CPU_DATA_EX;
>  
> +ACPI_CPU_DATA  *mAcpiCpuData;
> +
>  /**
>Allocate EfiACPIMemoryNVS below 4G memory address.
>  
> @@ -84,18 +86,31 @@ AllocateAcpiNvsMemoryBelow4G (
>  /**
>Callback function executed when the EndOfDxe event group is signaled.
>  
> -  We delay saving the MTRR settings until BDS signals EndOfDxe.
> +  We delay allocating StartupVector and saving the MTRR settings until BDS 
> signals EndOfDxe.
>  
>@param[in]  EventEvent whose notification function is being invoked.
>@param[out] Context  Pointer to the MTRR_SETTINGS buffer to fill in.
>  **/
>  VOID
>  EFIAPI
> -SaveMtrrsOnEndOfDxe (
> +CpuS3DataOnEndOfDxe (
>IN  EFI_EVENT  Event,
>OUT VOID   *Context
>)
>  {
> +  EFI_STATUS  Status;
> +  //
> +  // Allocate a 4KB reserved page below 1MB  //  
> + mAcpiCpuData->StartupVector = BASE_1MB - 1;  Status = 
> + gBS->AllocatePages (
> +  AllocateMaxAddress,
> +  EfiReservedMemoryType,
> +  1,
> +  >StartupVector
> +  );
> +  ASSERT_EFI_ERROR (Status);
> +
>DEBUG ((EFI_D_VERBOSE, "%a\n", __FUNCTION__));
>MtrrGetAllMtrrs (Context);
>  
> @@ -162,18 +177,6 @@ CpuS3DataInitialize (
>ASSERT_EFI_ERROR (Status);
>  
>//
> -  // Allocate a 4KB reserved page below 1MB
> -  //
> -  AcpiCpuData->StartupVector = BASE_1MB - 1;
> -  Status = gBS->AllocatePages (
> -  AllocateMaxAddress,
> -  EfiReservedMemoryType,
> -  1,
> -  >StartupVector
> -  );
> -  ASSERT_EFI_ERROR (Status);
> -
> -  //
>// Get the number of CPUs
>//
>Status = MpServices->GetNumberOfProcessors ( @@ -255,17 +258,19 @@ 
> CpuS3DataInitialize (
>  
>//
>// Register EFI_END_OF_DXE_EVENT_GROUP_GUID event.
> -  // The notification function saves MTRRs for ACPI_CPU_DATA
> +  // The notification function allocates StartupVector and saves 
> + MTRRs for ACPI_CPU_DATA
>//
>Status = gBS->CreateEventEx (
>EVT_NOTIFY_SIGNAL,
>TPL_CALLBACK,
> -  SaveMtrrsOnEndOfDxe,
> +  CpuS3DataOnEndOfDxe,
>>MtrrTable,
>,
>
>);
>ASSERT_EFI_ERROR (Status);
>  
> +  mAcpiCpuData = AcpiCpuData;
> +
>return EFI_SUCCESS;
>  }
> diff --git a/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf 
> b/UefiCpuPkg/CpuS3Dat

Re: [edk2] [Patch v3 34/40] OvmfPkg: Add MpInitLib reference in DSC files.

[Fan, Jeff]

Laszlo,

I am using TortoiseGit to create the patches. I can see the patch only includes 
the diff of DSC file as below in .patch file. I attached it for your reference.

@@ -213,6 +213,7 @@
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
+  MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
 
 [LibraryClasses.common.DXE_CORE]
   HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -292,6 +293,7 @@
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
 !endif
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
+  MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf

If you cannot see the diff part, what did you see in this patch through your 
mail application?

Thanks!
Jeff

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Monday, July 25, 2016 11:44 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Justen, Jordan L; Tian, Feng
Subject: Re: [edk2] [Patch v3 34/40] OvmfPkg: Add MpInitLib reference in DSC 
files.

On 07/25/16 04:52, Jeff Fan wrote:
> This update is for CpuMpPei consuming MP Initialize library.
> 
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 2 ++
>  OvmfPkg/OvmfPkgIa32X64.dsc | 2 ++
>  OvmfPkg/OvmfPkgX64.dsc | 2 ++
>  3 files changed, 6 insertions(+)

Please update your git configuration according to the following:

*
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05

  git config diff.ini.xfuncname '^\[[A-Za-z0-9_., ]+]'

* and
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-09

i.e., please add the following to " .git/info/attributes":

*.dec diff=ini
*.dsc diff=ini
*.dsc.inc diff=ini
*.fdf diff=ini
*.fdf.inc diff=ini
*.inf diff=ini

If you do that, then I'll be able to see from the patch itself what sections in 
the DSC file are being modified.

Thanks
Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v3 04/40] UefiCpuPkg/MpInitLib: Add MP Initialize library class definition

[Fan, Jeff]

Laszlo,

I added my comments after [Jeff] for your each comment.

Thanks!
Jeff
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Monday, July 25, 2016 9:53 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Tian, Feng
Subject: Re: [edk2] [Patch v3 04/40] UefiCpuPkg/MpInitLib: Add MP Initialize 
library class definition

On 07/25/16 04:52, Jeff Fan wrote:
> MP Initialize library provides basic functionalities to do APs 
> initialization, to manage MP information and to wakeup APs to execute AP task.
> 
> It could be consumed by CPU MP PEI or DXE drivers to provide CPU MP 
> PPI/Protocol services.
> 
> v3:
>   1. Add whitespace after MpInitLibInitialize
>   2. Rename MpInitLibSwitchBsp to MpInitLibSwitchBSP to match PI spec
> 
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Giri P Mudusuru <giri.p.mudus...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> Reviewed-by: Giri P Mudusuru <giri.p.mudus...@intel.com>
> ---
>  UefiCpuPkg/Include/Library/MpInitLib.h | 352 
> +
>  UefiCpuPkg/UefiCpuPkg.dec  |   4 +
>  2 files changed, 356 insertions(+)
>  create mode 100644 UefiCpuPkg/Include/Library/MpInitLib.h

(1) I guess "MpServicesLib" would be a better library class name, but it's not 
a big issue.

If you decide to change the name, then a number of other locations have to be 
changed as well (for example, the include guard).
[Jeff]  I agree MpServicesLib is good name. 
  Actually,  we have one plan to add one new library based on MP 
Services PPI/Protocols to provide basic MP functions. MpServiceLib is better 
for this module and located at MdePkg.
  So, MpServciesLib could be used by Pei/Dxe module/library that want 
to consume MP PPI/Protocol services.
  MpInitLib will be used by CpuPei/Dxe module that want to produce MP 
PPI/Protocol services.

> diff --git a/UefiCpuPkg/Include/Library/MpInitLib.h 
> b/UefiCpuPkg/Include/Library/MpInitLib.h
> new file mode 100644
> index 000..4ae02fb
> --- /dev/null
> +++ b/UefiCpuPkg/Include/Library/MpInitLib.h
> @@ -0,0 +1,352 @@
> +/** @file
> +  Multiple-Processor initialization Library.
> +
> +  Copyright (c) 2016, Intel Corporation. All rights reserved.  
> + This program and the accompanying materials  are licensed and made 
> + available under the terms and conditions of the BSD License  which 
> + accompanies this distribution.  The full text of the license may be 
> + found at  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" 
> + BASIS,  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS 
> OR IMPLIED.
> +
> +**/
> +
> +#ifndef __MP_INIT_LIB_H__
> +#define __MP_INIT_LIB_H__
> +
> +#include 
> +
> +/**
> +  MP Initialize Library initialization.
> +
> +  This service will allocate AP reset vector and wakeup all APs to do 
> + APs  initialization.
> +
> +  This service must be invoked before all other MP Initialize Library  
> + service are invoked.
> +
> +  @retval  EFI_SUCCESS   MP initialization succeeds.
> +  @retval  OthersMP initialization fails.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +MpInitLibInitialize (
> +  VOID
> +  );
> +
> +/**
> +  Retrieves the number of logical processor in the platform and the 
> +number of
> +  those logical processors that are enabled on this boot. This 
> +service may only
> +  be called from the BSP.
> +
> +  @param[out] NumberOfProcessors  Pointer to the total number of 
> logical
> +  processors in the system, 
> including the BSP
> +  and disabled APs.
> +  @param[out] NumberOfEnabledProcessors   Pointer to the number of enabled 
> logical
> +  processors that exist in system, 
> including
> +  the BSP.
> +
> +  @retval EFI_SUCCESS The number of logical processors and 
> enabled 
> +  logical processors was retrieved.
> +  @retval EFI_DEVICE_ERRORThe calling processor is an AP.
> +  @retval EFI_INVALID_PARAMETER   NumberOfProcessors is NULL and 
> NumberOfEnabledProcessors
> +  is NULL.

(2) "and" should be "or"
[Jeff] It should be "and".  MpInitLib allow each of parameter is NULL.

> +  @retval EFI_NOT_READY   MP Initialize

Re: [edk2] [Patch v3 06/40] UefiCpuPkg/MpInitLib: Add AP assembly code and MP_CPU_EXCHANGE_INFO

[Fan, Jeff]

Laszlo,

I added my comments after [Jeff] for your each comment.

Thanks!
Jeff

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Monday, July 25, 2016 11:33 PM
To: Fan, Jeff
Cc: edk2-de...@ml01.01.org; Kinney, Michael D; Tian, Feng
Subject: Re: [edk2] [Patch v3 06/40] UefiCpuPkg/MpInitLib: Add AP assembly code 
and MP_CPU_EXCHANGE_INFO

Jeff,

On 07/25/16 04:52, Jeff Fan wrote:
> Add assembly code for AP reset vector and the definition of 
> MP_CPU_EXCHANGE_INFO that are used to exchange the data between C code 
> and assembly code when AP wake up.
> 
> v3:
>   1. Rename NumApsExecutingLoction to NumApsExecutingLocation
>   2. Add whitespace after ; in .nasm file
> 
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Giri P Mudusuru <giri.p.mudus...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> Reviewed-by: Giri P Mudusuru <giri.p.mudus...@intel.com>
> ---
>  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf  |   8 ++
>  UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc|  37 +
>  UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm | 170 +++
>  UefiCpuPkg/Library/MpInitLib/MpLib.h   |  24 
>  UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf  |   8 ++
>  UefiCpuPkg/Library/MpInitLib/X64/MpEqu.inc |  39 ++
>  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm  | 178 
> +
>  7 files changed, 464 insertions(+)
>  create mode 100644 UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc
>  create mode 100644 UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
>  create mode 100644 UefiCpuPkg/Library/MpInitLib/X64/MpEqu.inc
>  create mode 100644 UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm

Patches like this (= patches that move code around, possibly tweaking
it) are extremely hard to review without dedicated help from the submitter. 
Such as:

- when copying a structure definition from another file, please spell
  out the origin of the structure definition. Example:
  MP_CPU_EXCHANGE_INFO comes from "UefiCpuPkg/CpuMpPei/CpuMpPei.h" with
  minimal changes.

- The patch should be please formatted with "--find-copies-harder". This
  will cause git to identify the best source file that may be the origin
  for a copy, and then express the new file as (copy + diff), rather
  than brand new code.

For example, I can look at this patch
(c661d4b85b748f03ed3e47c2b8424f797bdc0aaf) using git directly, from your repo, 
with the following options:

  git show --find-copies-harder --stat=1000 --stat-graph-width=20 \
c661d4b85b748f03ed3e47c2b8424f797bdc0aaf

It produces the following diffstat:

 UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf|   8 ++
 UefiCpuPkg/{CpuMpPei => Library/MpInitLib}/Ia32/MpEqu.inc|   8 +-
 UefiCpuPkg/{CpuMpPei => Library/MpInitLib}/Ia32/MpFuncs.nasm | 129 
+-
 UefiCpuPkg/Library/MpInitLib/MpLib.h |  24 
 UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf|   8 ++
 UefiCpuPkg/{CpuMpPei => Library/MpInitLib}/X64/MpEqu.inc |  10 +-
 UefiCpuPkg/{CpuMpPei => Library/MpInitLib}/X64/MpFuncs.nasm  | 141 
+++-
 7 files changed, 101 insertions(+), 227 deletions(-)

This tells me where the new files come from, and I can focus on the differences 
only. Otherwise, I have to review all of the code as brand new code, which is 
*immensely* more work.

Now, using the --find-copies-harder switch, I can see a number of unjustified 
differences immediately:

- "NumApsExecutingLoction" is replaced with "NumApsExecutingLocation".
  This is a typo fix, and should be in a separate patch.

- EnableExecuteDisableLocation and Cr3Location are new. The commit
  message should describe these fields in detail, and why they are
  necessary. (In practice, how we differ from CpuMpPei here.)

- The whitespace after ";" is actually a bad idea for this patch. It is
  in the same category as typo fixes: they can be justified, of course,
  but only as separate patches, so that they aren't intermixed with
  semantic changes.

- I see a few more changes of the same class (invoke -> Invoke, never ->
  Never)

I'm not a UefiCpuPkg maintainer, so technically my review is not necessary 
here. If you CC'd me so that I *test* the series, I'm happy to do it, and 
report back with results. However, if you'd like me to
*review* the series, then I'll need a *lot* more detail in the commit messages 
-- in practice you'll have to document your entire thought process. Every 
decision that is based on your knowledge with CpuMpPei and CpuMpDxe (which 
could be obvious to other UefiCpuPkg maintainers) will have to be spelled out 
for me in the commit messages

Re: [edk2] [Patch v3 04/40] UefiCpuPkg/MpInitLib: Add MP Initialize library class definition

[Fan, Jeff]

Laszlo,

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, July 26, 2016 4:31 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Tian, Feng
Subject: Re: [edk2] [Patch v3 04/40] UefiCpuPkg/MpInitLib: Add MP Initialize 
library class definition

On 07/26/16 04:43, Fan, Jeff wrote:
> Laszlo,
> 
> I added my comments after [Jeff] for your each comment.
> 
> Thanks!
> Jeff
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, July 25, 2016 9:53 PM
> To: Fan, Jeff; edk2-de...@ml01.01.org
> Cc: Kinney, Michael D; Tian, Feng
> Subject: Re: [edk2] [Patch v3 04/40] UefiCpuPkg/MpInitLib: Add MP 
> Initialize library class definition
> 
> On 07/25/16 04:52, Jeff Fan wrote:
>> MP Initialize library provides basic functionalities to do APs 
>> initialization, to manage MP information and to wakeup APs to execute AP 
>> task.
>>
>> It could be consumed by CPU MP PEI or DXE drivers to provide CPU MP 
>> PPI/Protocol services.
>>
>> v3:
>>   1. Add whitespace after MpInitLibInitialize
>>   2. Rename MpInitLibSwitchBsp to MpInitLibSwitchBSP to match PI spec
>>
>> Cc: Michael Kinney <michael.d.kin...@intel.com>
>> Cc: Feng Tian <feng.t...@intel.com>
>> Cc: Giri P Mudusuru <giri.p.mudus...@intel.com>
>> Cc: Laszlo Ersek <ler...@redhat.com>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Jeff Fan <jeff@intel.com>
>> Reviewed-by: Giri P Mudusuru <giri.p.mudus...@intel.com>
>> ---
>>  UefiCpuPkg/Include/Library/MpInitLib.h | 352 
>> +
>>  UefiCpuPkg/UefiCpuPkg.dec  |   4 +
>>  2 files changed, 356 insertions(+)
>>  create mode 100644 UefiCpuPkg/Include/Library/MpInitLib.h
> 
> (1) I guess "MpServicesLib" would be a better library class name, but it's 
> not a big issue.
> 
> If you decide to change the name, then a number of other locations have to be 
> changed as well (for example, the include guard).
> [Jeff]  I agree MpServicesLib is good name. 
>   Actually,  we have one plan to add one new library based on MP 
> Services PPI/Protocols to provide basic MP functions. MpServiceLib is better 
> for this module and located at MdePkg.
>   So, MpServciesLib could be used by Pei/Dxe module/library that want 
> to consume MP PPI/Protocol services.
> MpInitLib will be used by CpuPei/Dxe module that want to produce MP 
> PPI/Protocol services.

Okay, works for me.

>> diff --git a/UefiCpuPkg/Include/Library/MpInitLib.h
>> b/UefiCpuPkg/Include/Library/MpInitLib.h
>> new file mode 100644
>> index 000..4ae02fb
>> --- /dev/null
>> +++ b/UefiCpuPkg/Include/Library/MpInitLib.h
>> @@ -0,0 +1,352 @@
>> +/** @file
>> +  Multiple-Processor initialization Library.
>> +
>> +  Copyright (c) 2016, Intel Corporation. All rights reserved. 
>> + This program and the accompanying materials  are licensed and made 
>> + available under the terms and conditions of the BSD License  which 
>> + accompanies this distribution.  The full text of the license may be 
>> + found at  http://opensource.org/licenses/bsd-license.php
>> +
>> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" 
>> + BASIS,  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS 
>> OR IMPLIED.
>> +
>> +**/
>> +
>> +#ifndef __MP_INIT_LIB_H__
>> +#define __MP_INIT_LIB_H__
>> +
>> +#include 
>> +
>> +/**
>> +  MP Initialize Library initialization.
>> +
>> +  This service will allocate AP reset vector and wakeup all APs to 
>> + do APs  initialization.
>> +
>> +  This service must be invoked before all other MP Initialize 
>> + Library service are invoked.
>> +
>> +  @retval  EFI_SUCCESS   MP initialization succeeds.
>> +  @retval  OthersMP initialization fails.
>> +
>> +**/
>> +EFI_STATUS
>> +EFIAPI
>> +MpInitLibInitialize (
>> +  VOID
>> +  );
>> +
>> +/**
>> +  Retrieves the number of logical processor in the platform and the 
>> +number of
>> +  those logical processors that are enabled on this boot. This 
>> +service may only
>> +  be called from the BSP.
>> +
>> +  @param[out] NumberOfProcessors  Pointer to the total number of 
>> logical
>> +  processors in the system, 
>> including the BSP
>> +  and disabled APs.
>&g

Re: [edk2] [Patch v3 34/40] OvmfPkg: Add MpInitLib reference in DSC files.

[Fan, Jeff]

Laszlo,

Your method works for me. :-)

Thanks!
Jeff
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Tuesday, July 26, 2016 5:19 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Justen, Jordan L; Tian, Feng
Subject: Re: [edk2] [Patch v3 34/40] OvmfPkg: Add MpInitLib reference in DSC 
files.

On 07/26/16 05:27, Fan, Jeff wrote:
> Laszlo,
>
> I am using TortoiseGit to create the patches. I can see the patch only 
> includes the diff of DSC file as below in .patch file. I attached it 
> for your reference.
>
> @@ -213,6 +213,7 @@
>
> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentL
> ib.inf
>  !endif
>
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCp
> uExceptionHandlerLib.inf
> +  MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
>
>  [LibraryClasses.common.DXE_CORE]
>HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
> @@ -292,6 +293,7 @@
>
> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.
> inf
>  !endif
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
> +  MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>
> If you cannot see the diff part, what did you see in this patch 
> through your mail application?

I saw the patch just fine. It wasn't a problem with the email setup on either 
your end or on my end.

Instead, my comment was about the *formatting* of the patch.

When you format a patch with git (using "git show", "git diff", "git 
format-patch", and so on), the patch has so-called *hunk headers*. The hunk 
headers are the meta-lines with the "@@" markers and the line numbers in them.

In order to support the reviewing of patches, git can include additional 
context information in the hunk headers, after the second "@@" marker on the 
line. For C source code, this is usually the name of the function that's being 
patched.

For example, in your first patch in this series:

  http://thread.gmane.org/gmane.comp.bios.edk2.devel/15012/focus=15009

you modify the PeiSwitchBSP() function in the 
"UefiCpuPkg/CpuMpPei/PeiMpServices.c" file. Accordingly, the hunk header looks 
like this:

> diff --git a/UefiCpuPkg/CpuMpPei/PeiMpServices.c 
> b/UefiCpuPkg/CpuMpPei/PeiMpServices.c
> index e784377..e06fdf1 100644
> --- a/UefiCpuPkg/CpuMpPei/PeiMpServices.c
> +++ b/UefiCpuPkg/CpuMpPei/PeiMpServices.c
> @@ -1,7 +1,7 @@
>  /** @file
>Implementation of Multiple Processor PPI services.
>
> -  Copyright (c) 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2015 - 2016, Intel Corporation. All rights 
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
>which accompanies this distribution.  The full text of the license 
> may be found at @@ -729,9 +729,9 @@ PeiSwitchBSP (  
> <--- this line here
>IN  BOOLEAN  EnableOldBSP
>)
>  {
> -  PEI_CPU_MP_DATA *PeiCpuMpData;
> -  UINTN   CallerNumber;
> -  MSR_IA32_APIC_BASE  ApicBaseMsr;
> +  PEI_CPU_MP_DATA  *PeiCpuMpData;
> +  UINTNCallerNumber;
> +  MSR_IA32_APIC_BASE_REGISTER  ApicBaseMsr;
>
>PeiCpuMpData = GetMpHobData ();
>if (PeiCpuMpData == NULL) {

The hunk header identifies the PeiSwitchBSP() function by name, helping the 
reviewer look up / identify the function quickly.

Now, wouldn't it be grand if we could tell git to do the exact same thing for 
DSC, FDF, INF, and DEC files?

Obviously, the hunk headers should not carry C function names there, because 
those files are not C source files. However, these files have *sections*, and 
displaying the *section* being modified in the hunk header would be awesome.

We can actually tell git to do this. Two steps are necessary for that:

(1) marking these files, for the purpose of diffing, with a special file type

(2) for that special file type, adding a regular expression that matches the 
section headers.

For step (1), the file ".git/info/attributes" can be edited, and the following 
contents should be added:

*.dec diff=ini
*.dsc diff=ini
*.dsc.inc diff=ini
*.fdf diff=ini
*.fdf.inc diff=ini
*.inf diff=ini

After this, whenever git sees a *.dec file (for example) it will consider that 
file as having type "ini" for the purposes of diffing.
That in itself means nothing, of course.

However, for step (2), we do:

  git config diff.ini.xfuncname '^\[[A-Za-z0-9_., ]+]'

This tells git that for diffing files of type "ini", it should set the 
"xfuncname" interna

Re: [edk2] [Patch v3 00/40] MP Initialize Library

[Fan, Jeff]

Laszlo,

Many thanks for your verification. 

Your dump information and analysis result are very useful. I guess the issue 
happened at 
   UefiCpuPkg\PiSmmCpuDxeSmm\Ia32\MpFuncs.nasm:80 a32 jmp   dword 
0x20:0x0

The Proteted mode CS in current GDT table is not 0x20. But the PiSmmCpuDxeSmm 
hardcode it to 0x20.

I will try it fix it tomorrow and feedback to you. 

Thanks your support!
Jeff

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, July 28, 2016 9:24 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Subject: Re: [edk2] [Patch v3 00/40] MP Initialize Library

On 07/25/16 04:52, Jeff Fan wrote:
> We add MP Initialize Library defined in 
> UefiCpuPkg/Include/Library/MpInitLib.h.
> It will provide basic functionalities of MP services and could be 
> consumed by CPU MP PEI and CPU MP DXE to produce CPU MP PPI and CPU MP 
> Protocol. Then most of code could be shared between PEI and DXE modules.
> 
> PeiMpInitLib and DxeMpInitLib are added to make the CpuMpPei and 
> CpuDxe more simply.
> 
> I also updated the Ovmf Platform and Quark platform to consume MP 
> Initialize library. I have tested Ovmf platform and have not tested Quark yet.
> 
> v3:
>   1. Update Patch #2, #4 - #8, #28, #33, #36, #38 per Giri's comments to
>  a. Update SDM date to June, 2016
>  b. Mention BCD format in CPU_MICROCODE_DATE
>  c. Rename ProcessorChecksum to Checksum to match SDM.
>  d. Add whitespace after MpInitLibInitialize
>  e. Rename MpInitLibSwitchBsp to MpInitLibSwitchBSP to match PI spec.
>  f. Rename NumApsExecutingLoction to NumApsExecutingLocation
>  g. Add whitespace after ; in .nasm file
>  h. Rename *RellocateAp* to *RelocateAp*
>   2. Update Patch #16, #17, #29-#32 to
>  a. Use CamelCase for mStopCheckAllApsStatus and 
> CheckAndUpdateApsStatus().
>   3. Update Patch #36 and #39 to
>  a. Add PeiMpInitLib instance in UefiCpuPkg.dsc
>  b. Add DxeMpInitLib instance in UefiCpuPkg.dsc
>   4. Update Patch #39 and #40 to 
>  a. move the code of consuming MP Initialize library from patch #40 to
>  patch #39.
>   5. Update Patch #1, #3 - #8, #16 to
>  a. Add Reviewed-by: Giri P Mudusuru <giri.p.mudus...@intel.com>
> 
> I fork the whole tree with the updated v3 patches at 
> https://github.com/vanjeff/edk2/tree/MpInitLibV3 for review.

I rebased your branch (originally at 09948b72fbb7) on top of current master (= 
39dbc4d55347), and built it. It builds fine.

Scenarios that I tested, and seem to work:

* Q35, Ia32, with -D SMM_REQUIRE, 4 VCPUs, Fedora guest:
  - normal boot path: pass
  - S3 resume: FAIL (see details below)

* i440fx, X64, without -D SMM_REQUIRE, 8 VCPUs, Fedora guest:
  - normal boot path: pass
  - S3 resume: pass

I re-verified the fix for 
<https://tianocore.acgmultimedia.com/show_bug.cgi?id=86>, which requires 
CpuMpPei to actually *work* on both boot paths, and it works fine.

* Q35, Ia32X64, with -D SMM_REQUIRE, 4 VCPUs, Fedora guest:
  - normal boot path: pass

On the normal boot path, I also verified that the MTRR setup was consistent 
across the VCPUs (otherwise Linux would have complained), plus the fix for 
<https://tianocore.acgmultimedia.com/show_bug.cgi?id=86> was working fine too. 
I also checked that the UEFI variable services worked, bound to the BSP, and 
then bound to the first AP as well. (Using the "taskset" Linux command, with 
"efibootmgr", to list the variables.) I quickly checked that Secure Boot was 
still recognized by the guest (Fedora) as enabled.

  - S3 resume: pass

Repeated the BZ#86 check and the variable access checks from within the resumed 
guest, all pass.

* Q35, Ia32X64, with -D SMM_REQUIRE, 4 VCPUs, Windows 8.1 guest:
  - normal boot path: pass

On the normal boot path, I checked Secure Boot enablement with PowerShell.

  - S3 resume: pass.

Now, about the one failure case. QEMU logs the following:

> KVM internal error. Suberror: 3
> KVM internal error. Suberror: 3
> KVM internal error. Suberror: 3
> extra data[0]: 8b0d
> extra data[0]: 8b0d
> extra data[1]: 31
> extra data[1]: 31
> extra data[0]: 8b0d
> extra data[1]: 31
>
> EAX=6011 EBX= ECX= EDX=0009f000
> ESI=00b5 EDI= EBP= ESP=
> EIP=0032 EFL=00010006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES 
> =9f00 0009f000  9300 DPL=0 DS16 [-WA] CS =9f00 0009f000 
>  9b00 DPL=0 CS16 [-RA] SS =9f00 0009f000  9300 
> DPL=0 DS16 [-WA] DS =   9300 DPL=0 DS16 [-WA] 
> FS =   9300 DPL=0 DS16 [-WA] GS =  
>  9300 DPL=0 DS16 [-WA]
> LDT=   8200 DPL=0 LDT TR =  
>  8b00 DPL=0 TSS32-busy
> GDT= 7f2d8000 001

Re: [edk2] [Patch v2 02/40] UefiCpuPkg/MpInitLib: Add microcode definitions defined in IA32 SDM

[Fan, Jeff]

Giri,

I added my feedback in [Jeff] in your last mail body.

And I agree with your current comments on other patches. I will update the code 
per your comments in v2 patches list.

Thanks!
Jeff

-Original Message-
From: Mudusuru, Giri P 
Sent: Friday, July 22, 2016 12:33 PM
To: Fan, Jeff; edk2-devel@lists.01.org
Cc: Kinney, Michael D; Tian, Feng; Laszlo Ersek
Subject: RE: [Patch v2 02/40] UefiCpuPkg/MpInitLib: Add microcode definitions 
defined in IA32 SDM

Few comments
1) Please update the SDM reference to the latest version from June.
[Jeff] Agree.

2) Add comment for Microcode date CPU_MICROCODE_DATE that it is in BCD format
[Jeff] Agree.

3) use /** **/ block comments for multiple line comments
[Jeff] Both /** **/ and /// should be legal for Doxgen format. 
  or multiple line comments, /// is the example for structure in EDKII 
code style document. 
https://github.com/tianocore-docs/Docs/raw/master/Specifications/CCS_2_1_Draft.pdf

4) change ProcessorChecksum to Checksum in CPU_MICROCODE_EXTENDED_TABLE to 
align with SDM
[Jeff] Agree. Good catch.

Thanks,
-Giri

> -Original Message-
> From: Fan, Jeff
> Sent: Thursday, July 21, 2016 8:14 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Tian, Feng 
> <feng.t...@intel.com>; Mudusuru, Giri P <giri.p.mudus...@intel.com>; 
> Laszlo Ersek <ler...@redhat.com>
> Subject: [Patch v2 02/40] UefiCpuPkg/MpInitLib: Add microcode 
> definitions defined in IA32 SDM
> 
> Add microcode definitions defined in Intel(R) 64 and IA-32 
> Architectures Software Developer's Manual Volume 3A, Section 9.11.
> 
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Giri P Mudusuru <giri.p.mudus...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> ---
>  UefiCpuPkg/Include/Register/Microcode.h | 196
> 
>  1 file changed, 196 insertions(+)
>  create mode 100644 UefiCpuPkg/Include/Register/Microcode.h
> 
> diff --git a/UefiCpuPkg/Include/Register/Microcode.h
> b/UefiCpuPkg/Include/Register/Microcode.h
> new file mode 100644
> index 000..213f659
> --- /dev/null
> +++ b/UefiCpuPkg/Include/Register/Microcode.h
> @@ -0,0 +1,196 @@
> +/** @file
> +  Microcode Definitions.
> +
> +  Microcode Definitions based on contents of the
> +  Intel(R) 64 and IA-32 Architectures Software Developer's Manual
> +Volume 3A, Section 9.11  Microcode Definitions
> +
> +  Copyright (c) 2016, Intel Corporation. All rights reserved.  
> + This program and the accompanying materials  are licensed and made 
> + available under the terms and conditions of the BSD
> License
> +  which accompanies this distribution.  The full text of the license 
> + may be found
> at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +  @par Specification Reference:
> +  Intel(R) 64 and IA-32 Architectures Software Developer's Manual, 
> + Volume 3A,  April 2016, Chapter 9 Processor Management and Initialization, 
> Section 9-11.
> +
> +**/
> +
> +#ifndef __MICROCODE_H__
> +#define __MICROCODE_H__
> +
> +///
> +/// CPU Microcode Date format
> +///
> +typedef union {
> +  struct {
> +UINT32   Year:16;
> +UINT32   Day:8;
> +UINT32   Month:8;
> +  } Bits;
> +  UINT32 Uint32;
> +} CPU_MICROCODE_DATE;
> +
> +///
> +/// CPU Microcode Processor Signature format /// typedef union {
> +  struct {
> +UINT32   Stepping:4;
> +UINT32   Model:4;
> +UINT32   Family:4;
> +UINT32   Type:2;
> +UINT32   Reserved1:2;
> +UINT32   ExtendedModel:4;
> +UINT32   ExtendedFamily:8;
> +UINT32   Reserved2:4;
> +  } Bits;
> +  UINT32 Uint32;
> +} CPU_MICROCODE_PROCESSOR_SIGNATURE;
> +
> +///
> +/// Microcode Update Format definition /// typedef struct {
> +  ///
> +  /// Version number of the update header
> +  ///
> +  UINT32HeaderVersion;
> +  ///
> +  /// Unique version number for the update, the basis for the update
> +  /// signature provided by the processor to indicate the current 
> +update
> +  /// functioning within the processor. Used by the BIOS to 
> +authenticate
> +  /// the update and verify that the processor loads successfully. 
> +The
> +  /// value in this field cannot be used for processor stepping 
> +identification
> +  /// alone. This is a signed 32-bit number.
&

Re: [edk2] [Patch 2/3] MdePkg PeiDxePostCodeLibReportStatusCode: Correct files with CRLF line ending

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Thursday, July 28, 2016 4:46 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 2/3] MdePkg PeiDxePostCodeLibReportStatusCode: Correct 
files with CRLF line ending

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming@intel.com>
---
 .../PeiDxePostCodeLibReportStatusCode.inf | 4 ++--
 .../PeiDxePostCodeLibReportStatusCode.uni | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/MdePkg/Library/PeiDxePostCodeLibReportStatusCode/PeiDxePostCodeLibReportStatusCode.inf
 
b/MdePkg/Library/PeiDxePostCodeLibReportStatusCode/PeiDxePostCodeLibReportStatusCode.inf
index 6189cf2..dc162c2 100644
--- 
a/MdePkg/Library/PeiDxePostCodeLibReportStatusCode/PeiDxePostCodeLibReportStatusCode.inf
+++ b/MdePkg/Library/PeiDxePostCodeLibReportStatusCode/PeiDxePostCodeLib
+++ ReportStatusCode.inf
@@ -1,7 +1,7 @@
 ## @file
-# Instance of Post Code Library based on Report Status Code Library.
+# Instance of Post Code Library based on Report Status Code Library.
 #
-# Post Code Library that layers on top of a Report Status Code Library 
instance.
+# Post Code Library that layers on top of a Report Status Code Library 
instance.
 #
 # Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.  # 
diff --git 
a/MdePkg/Library/PeiDxePostCodeLibReportStatusCode/PeiDxePostCodeLibReportStatusCode.uni
 
b/MdePkg/Library/PeiDxePostCodeLibReportStatusCode/PeiDxePostCodeLibReportStatusCode.uni
index bc7387c..165f27f 100644
--- 
a/MdePkg/Library/PeiDxePostCodeLibReportStatusCode/PeiDxePostCodeLibReportStatusCode.uni
+++ b/MdePkg/Library/PeiDxePostCodeLibReportStatusCode/PeiDxePostCodeLib
+++ ReportStatusCode.uni
@@ -1,7 +1,7 @@
 // /** @file
-// Instance of Post Code Library based on Report Status Code Library.
+// Instance of Post Code Library based on Report Status Code Library.
 //
-// Post Code Library that layers on top of a Report Status Code Library 
instance.
+// Post Code Library that layers on top of a Report Status Code Library 
instance.
 //
 // Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.  //
--
2.8.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v3 00/40] MP Initialize Library

[Fan, Jeff]

Laszlo,

I sent one evaluate patch for you by adding back GDT table load in CpuDxe. 
Could you please help to verify if it could fix IA32 S3 issue?

Another solution is to remove hardcode from PiSmmCpuDxeSmm driver. But I do not 
prefer to do it this time. :-)

Thanks!
Jeff

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Thursday, July 28, 2016 11:21 PM
To: Fan, Jeff
Cc: edk2-de...@ml01.01.org
Subject: Re: [edk2] [Patch v3 00/40] MP Initialize Library

On 07/28/16 15:55, Fan, Jeff wrote:
> Laszlo,
> 
> Many thanks for your verification. 
> 
> Your dump information and analysis result are very useful. I guess the issue 
> happened at 
>UefiCpuPkg\PiSmmCpuDxeSmm\Ia32\MpFuncs.nasm:80 a32 jmp   dword 
> 0x20:0x0
> 
> The Proteted mode CS in current GDT table is not 0x20. But the PiSmmCpuDxeSmm 
> hardcode it to 0x20.

Ah, good point; I recall:

commit 0d4c1db81aab86963536deb8253f35546c4398ea
Author: Michael Kinney <michael.d.kin...@intel.com>
Date:   Fri Oct 30 17:32:27 2015 +

UefiCpuPkg: CpuDxe: Update GDT to be consistent with DxeIplPeim

as another related patch.

> I will try it fix it tomorrow and feedback to you. 

Thank you, I'll attempt to test it soon after.

Cheers
Laszlo

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, July 28, 2016 9:24 PM
> To: Fan, Jeff; edk2-de...@ml01.01.org
> Subject: Re: [edk2] [Patch v3 00/40] MP Initialize Library
> 
> On 07/25/16 04:52, Jeff Fan wrote:
>> We add MP Initialize Library defined in 
>> UefiCpuPkg/Include/Library/MpInitLib.h.
>> It will provide basic functionalities of MP services and could be 
>> consumed by CPU MP PEI and CPU MP DXE to produce CPU MP PPI and CPU 
>> MP Protocol. Then most of code could be shared between PEI and DXE modules.
>>
>> PeiMpInitLib and DxeMpInitLib are added to make the CpuMpPei and 
>> CpuDxe more simply.
>>
>> I also updated the Ovmf Platform and Quark platform to consume MP 
>> Initialize library. I have tested Ovmf platform and have not tested Quark 
>> yet.
>>
>> v3:
>>   1. Update Patch #2, #4 - #8, #28, #33, #36, #38 per Giri's comments to
>>  a. Update SDM date to June, 2016
>>  b. Mention BCD format in CPU_MICROCODE_DATE
>>  c. Rename ProcessorChecksum to Checksum to match SDM.
>>  d. Add whitespace after MpInitLibInitialize
>>  e. Rename MpInitLibSwitchBsp to MpInitLibSwitchBSP to match PI spec.
>>  f. Rename NumApsExecutingLoction to NumApsExecutingLocation
>>  g. Add whitespace after ; in .nasm file
>>  h. Rename *RellocateAp* to *RelocateAp*
>>   2. Update Patch #16, #17, #29-#32 to
>>  a. Use CamelCase for mStopCheckAllApsStatus and 
>> CheckAndUpdateApsStatus().
>>   3. Update Patch #36 and #39 to
>>  a. Add PeiMpInitLib instance in UefiCpuPkg.dsc
>>  b. Add DxeMpInitLib instance in UefiCpuPkg.dsc
>>   4. Update Patch #39 and #40 to 
>>  a. move the code of consuming MP Initialize library from patch #40 to
>>  patch #39.
>>   5. Update Patch #1, #3 - #8, #16 to
>>  a. Add Reviewed-by: Giri P Mudusuru <giri.p.mudus...@intel.com>
>>
>> I fork the whole tree with the updated v3 patches at
>> https://github.com/vanjeff/edk2/tree/MpInitLibV3 for review.
> 
> I rebased your branch (originally at 09948b72fbb7) on top of current master 
> (= 39dbc4d55347), and built it. It builds fine.
> 
> Scenarios that I tested, and seem to work:
> 
> * Q35, Ia32, with -D SMM_REQUIRE, 4 VCPUs, Fedora guest:
>   - normal boot path: pass
>   - S3 resume: FAIL (see details below)
> 
> * i440fx, X64, without -D SMM_REQUIRE, 8 VCPUs, Fedora guest:
>   - normal boot path: pass
>   - S3 resume: pass
> 
> I re-verified the fix for 
> <https://tianocore.acgmultimedia.com/show_bug.cgi?id=86>, which requires 
> CpuMpPei to actually *work* on both boot paths, and it works fine.
> 
> * Q35, Ia32X64, with -D SMM_REQUIRE, 4 VCPUs, Fedora guest:
>   - normal boot path: pass
> 
> On the normal boot path, I also verified that the MTRR setup was consistent 
> across the VCPUs (otherwise Linux would have complained), plus the fix for 
> <https://tianocore.acgmultimedia.com/show_bug.cgi?id=86> was working fine 
> too. I also checked that the UEFI variable services worked, bound to the BSP, 
> and then bound to the first AP as well. (Using the "taskset" Linux command, 
> with "efibootmgr", to list the variables.) I quickly checked that Secure Boot 
> was still recognized by the guest (Fedora) as enabled.
> 
>   - S3 resume: pass
> 
> Repeated the BZ#86 ch

Re: [edk2] [PATCH v2 4/5] OvmfPkg: include UefiCpuPkg/CpuMpPei

[Fan, Jeff]

Laszlo,

Even I have r-b this patch before, I have one comment now. :-)

It's better to move PeiCpuExceptionHandlerLib instance from CpuMpPei to

 [LibraryClasses.common.PEIM]
  + 
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf

It's more generic and consist with other CpuExceptionHandlerLib instance.

Thanks!
Jeff

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, July 13, 2016 8:18 AM
To: edk2-devel-01
Cc: Fan, Jeff; Justen, Jordan L; Kinney, Michael D
Subject: [PATCH v2 4/5] OvmfPkg: include UefiCpuPkg/CpuMpPei

In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use.

CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond those 
already used by CpuDxe:

- PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these
  control whether CpuMpPei performs microcode update. If the region size
  is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the
  region size to zero by default, which is appropriate for OVMF.

- PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how
  CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait
  (with PAUSE). The latter PCD is only relevant if the former PCD is 2
  (MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself,
  we choose HLT. That's the default set by UefiCpuPkg.dec.

Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib 
technically, it is supposed to consume PeiCpuExceptionHandlerLib. See:

- http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703

- git commit a81abf161666 ("UefiCpuPkg/ExceptionLib: Import
  PeiCpuExceptionHandlerLib module"), part of the series linked above.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Michael Kinney <michael.d.kin...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
Reviewed-by: Jeff Fan <jeff@intel.com>
---
 OvmfPkg/OvmfPkgIa32.dsc| 5 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 5 +
 OvmfPkg/OvmfPkgX64.dsc | 5 +
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 6 files changed, 18 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 
6d074641bede..611505e5d188 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -519,6 +519,11 @@ [Components]
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   }
 !endif
+  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
+
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+  
+ CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCp
+ uExceptionHandlerLib.inf
+  }
 
   #
   # DXE Phase modules
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index 
25fcb38aaf84..92b373dfe3ee 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -527,6 +527,11 @@ [Components.IA32]
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   }
 !endif
+  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
+
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+  
+ CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCp
+ uExceptionHandlerLib.inf
+  }
 
 [Components.X64]
   #
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index 
cb7ccf79618d..255ac79e3e34 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -526,6 +526,11 @@ [Components]
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   }
 !endif
+  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
+
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+  
+ CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCp
+ uExceptionHandlerLib.inf
+  }
 
   #
   # DXE Phase modules
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index 
be3ba417f938..684484fc422d 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -161,6 +161,7 @@ [FV.PEIFV]
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccessPei.inf
 !endif
+INF  UefiCpuPkg/CpuMpPei/CpuMpPei.inf
 
 

 
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf index 
38f23605d2d4..a13cc0a3ed5b 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -161,6 +161,7 @@ [FV.PEIFV]
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccessPei.inf
 !endif
+INF  UefiCpuPkg/CpuMpPei/CpuMpPei.inf
 
 

 
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf index 
7d06a62001fd..a64836073a21 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -161,6 +161,7 @@ [FV.PEIFV]
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccessPei.inf
 !endi

Re: [edk2] [PATCH v2 3/5] OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySize

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, July 13, 2016 8:18 AM
To: edk2-devel-01
Cc: Fan, Jeff; Justen, Jordan L; Kinney, Michael D
Subject: [PATCH v2 3/5] OvmfPkg: remove PcdS3AcpiReservedMemoryBase, 
PcdS3AcpiReservedMemorySize

No module in OvmfPkg uses these PCDs any longer.

The first PCD mentioned is declared by OvmfPkg, so we can remove even the 
declaration.

The second PCD comes from IntelFrameworkModulePkg. The module that consumes 
PcdS3AcpiReservedMemorySize is called 
"IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe", and it is built into 
OVMF. However, AcpiS3SaveDxe consumes the PCD only conditionally: it depends on 
the feature PCD called PcdFrameworkCompatibilitySupport, which we never enable 
in OVMF.

The 32KB gap that used to be the S3 permanent PEI memory is left unused in 
MEMFD for now; it never hurts to have a few KB available there, for future 
features.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Michael Kinney <michael.d.kin...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
---

Notes:
v2:
- new in v2 [Jordan]

 OvmfPkg/OvmfPkg.dec| 1 -
 OvmfPkg/OvmfPkgIa32.fdf| 3 ---
 OvmfPkg/OvmfPkgIa32X64.fdf | 3 ---
 OvmfPkg/OvmfPkgX64.fdf | 3 ---
 4 files changed, 10 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec index 
54734f7f843a..a0c76a5bb448 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -105,7 +105,6 @@ [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize|0x0|UINT32|0x12
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|0x0|UINT32|0x13
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize|0x0|UINT32|0x14
-  gUefiOvmfPkgTokenSpaceGuid.PcdS3AcpiReservedMemoryBase|0x0|UINT32|0x17
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|0x0|UINT32|0x18
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize|0x0|UINT32|0x19
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index 
664a035f181d..be3ba417f938 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -84,9 +84,6 @@ [FD.MEMFD]
 0x01|0x008000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
-0x018000|0x008000
-gUefiOvmfPkgTokenSpaceGuid.PcdS3AcpiReservedMemoryBase|gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
-
 0x02|0x0E
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
 FV = PEIFV
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf index 
0f5fe51d7ba2..38f23605d2d4 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -84,9 +84,6 @@ [FD.MEMFD]
 0x01|0x008000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
-0x018000|0x008000
-gUefiOvmfPkgTokenSpaceGuid.PcdS3AcpiReservedMemoryBase|gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
-
 0x02|0x0E
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
 FV = PEIFV
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf index 
6e468a8ab066..7d06a62001fd 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -84,9 +84,6 @@ [FD.MEMFD]
 0x01|0x008000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
-0x018000|0x008000
-gUefiOvmfPkgTokenSpaceGuid.PcdS3AcpiReservedMemoryBase|gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
-
 0x02|0x0E
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
 FV = PEIFV
--
1.8.3.1


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/5] OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, July 13, 2016 8:18 AM
To: edk2-devel-01
Cc: Fan, Jeff; Justen, Jordan L; Kinney, Michael D
Subject: [PATCH v2 2/5] OvmfPkg/PlatformPei: rebase and resize the permanent 
PEI memory for S3

Move the permanent PEI memory for the S3 resume boot path to the top of the low 
RAM (just below TSEG if the SMM driver stack is included in the build). The new 
size is derived from CpuMpPei's approximate memory demand.

Save the base address and the size in new global variables, regardless of the 
boot path. On the normal boot path, use these variables for covering the area 
with EfiACPIMemoryNVS type memory.

PcdS3AcpiReservedMemoryBase and PcdS3AcpiReservedMemorySize become unused in 
PlatformPei; remove them.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Michael Kinney <michael.d.kin...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
---

Notes:
v2:
- new in v2 [Jordan, Jeff]

 OvmfPkg/PlatformPei/PlatformPei.inf |  3 +-
 OvmfPkg/PlatformPei/MemDetect.c | 39 ++--
 2 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 3556404017fc..229831b10da0 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -65,7 +65,6 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
-  gUefiOvmfPkgTokenSpaceGuid.PcdS3AcpiReservedMemoryBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
@@ -82,7 +81,6 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
@@ -95,6 +93,7 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
 
 [FixedPcd]
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c 
index d59b461547c5..7129ed26fa3e 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -39,6 +39,9 @@ Module Name:
 
 UINT8 mPhysMemAddressWidth;
 
+STATIC UINT32 mS3AcpiReservedMemoryBase; STATIC UINT32 
+mS3AcpiReservedMemorySize;
+
 UINT32
 GetSystemMemorySizeBelow4gb (
   VOID
@@ -335,18 +338,30 @@ PublishPeiMemory (
   UINT64  LowerMemorySize;
   UINT32  PeiMemoryCap;
 
+  LowerMemorySize = GetSystemMemorySizeBelow4gb ();  if (FeaturePcdGet 
+ (PcdSmmSmramRequire)) {
+//
+// TSEG is chipped from the end of low RAM
+//
+LowerMemorySize -= FixedPcdGet8 (PcdQ35TsegMbytes) * SIZE_1MB;  }
+
+  //
+  // If S3 is supported, then the S3 permanent PEI memory is placed 
+ next,  // downwards. Its size is primarily dictated by CpuMpPei. The 
+ formula below  // is an approximation.
+  //
+  if (mS3Supported) {
+mS3AcpiReservedMemorySize = SIZE_512KB +
+  PcdGet32 (PcdCpuMaxLogicalProcessorNumber) * SIZE_32KB;
+mS3AcpiReservedMemoryBase = LowerMemorySize - mS3AcpiReservedMemorySize;
+LowerMemorySize = mS3AcpiReservedMemoryBase;  }
+
   if (mBootMode == BOOT_ON_S3_RESUME) {
-MemoryBase = PcdGet32 (PcdS3AcpiReservedMemoryBase);
-MemorySize = PcdGet32 (PcdS3AcpiReservedMemorySize);
+MemoryBase = mS3AcpiReservedMemoryBase;
+MemorySize = mS3AcpiReservedMemorySize;
   } else {
-LowerMemorySize = GetSystemMemorySizeBelow4gb ();
-if (FeaturePcdGet (PcdSmmSmramRequire)) {
-  //
-  // TSEG is chipped from the end of low RAM
-  //
-  LowerMemorySize -= FixedPcdGet8 (PcdQ35TsegMbytes) * SIZE_1MB;
-}
-
 PeiMemoryCap = GetPeiMemoryCap ();
 DEBUG ((EFI_D_INFO, "%a: mPhysMemAddressWidth=%d PeiMemoryCap=%u KB\n",
   __FUNCTION__, mPhysMemAddressWidth, PeiMemoryCap >> 10)); @@ -514,8 
+529,8 @@ InitializeRamRegions (
 // This is the memory range that will be used for PEI on S3 resume
 //
 BuildMemoryAllocationHob (
-  (EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdS3AcpiReservedMemoryBase),
-  (UINT64)(UINTN) PcdGet32 (PcdS3AcpiReservedMemorySize),
+  mS3AcpiReservedMemoryBase,
+  mS3AcpiReservedMemorySize,

Re: [edk2] [PATCH v3 0/5] OvmfPkg: program MSR_IA32_FEATURE_CONTROL from fw_cfg on all processors

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, July 13, 2016 10:37 PM
To: edk2-devel-01
Cc: Fan, Jeff; Justen, Jordan L; Kinney, Michael D
Subject: [PATCH v3 0/5] OvmfPkg: program MSR_IA32_FEATURE_CONTROL from fw_cfg 
on all processors

v1: http://thread.gmane.org/gmane.comp.bios.edk2.devel/14214
v2: http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471

Changes relative to v2:
- Patches 2 and 3: pick up Jeff's R-b.
- Patch 4: resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib
  for all PEIMs (suggested by Jeff). Drop Jeff's earlier R-b.

Public branch:
<https://github.com/lersek/edk2/commits/feat_ctrl_issue97_v3>.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Michael Kinney <michael.d.kin...@intel.com>

Thanks
Laszlo

Laszlo Ersek (5):
  OvmfPkg/PlatformPei: create one memory HOB at S3 resume too, for
CpuMpPei
  OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3
  OvmfPkg: remove PcdS3AcpiReservedMemoryBase,
PcdS3AcpiReservedMemorySize
  OvmfPkg: include UefiCpuPkg/CpuMpPei
  OvmfPkg/PlatformPei: program MSR_IA32_FEATURE_CONTROL from fw_cfg

 OvmfPkg/OvmfPkg.dec  |   1 -
 OvmfPkg/OvmfPkgIa32.dsc  |   5 +
 OvmfPkg/OvmfPkgIa32X64.dsc   |   5 +
 OvmfPkg/OvmfPkgX64.dsc   |   5 +
 OvmfPkg/OvmfPkgIa32.fdf  |   4 +-
 OvmfPkg/OvmfPkgIa32X64.fdf   |   4 +-
 OvmfPkg/OvmfPkgX64.fdf   |   4 +-
 OvmfPkg/PlatformPei/PlatformPei.inf  |   5 +-
 OvmfPkg/PlatformPei/Platform.h   |   5 +
 OvmfPkg/PlatformPei/FeatureControl.c | 134 
 OvmfPkg/PlatformPei/MemDetect.c  |  63 +++--
 OvmfPkg/PlatformPei/Platform.c   |   1 +
 12 files changed, 211 insertions(+), 25 deletions(-)  create mode 100644 
OvmfPkg/PlatformPei/FeatureControl.c

--
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] UefiCpuPkg/MtrrLib: Remove MTRRs display from MtrrSetAllMtrrs()

[Fan, Jeff]

Brian,

Good point on BSP bit in MSR_IA32_APIC_BASE register.  But some processor(for 
example, Quark) does not support this MSR.
//
// CPUs with a FamilyId of 0x04 or 0x05 do not support the 
// Local APIC Base Address MSR
//

I think the generic solution is still to remove MTRRs display from 
MtrrSetAllMtrrs(). 

Thanks!
Jeff

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Brian J. 
Johnson
Sent: Thursday, July 14, 2016 2:36 AM
To: Laszlo Ersek; Kinney, Michael D; Fan, Jeff; edk2-de...@ml01.01.org
Cc: Tian, Feng
Subject: Re: [edk2] [Patch] UefiCpuPkg/MtrrLib: Remove MTRRs display from 
MtrrSetAllMtrrs()

On 07/13/2016 11:19 AM, Laszlo Ersek wrote:
> On 07/13/16 17:46, Kinney, Michael D wrote:
>> Laszlo,
>>
>> I agree that the DEBUG() messages for this are very valuable to debug 
>> MTRR cache settings.
>>
>> Another option is to add logic to detect if the calling CPU is the 
>> BSP or not and only invoke DEBUG() macros if the caller is the BSP.  
>> That would not require any changes to the MtrrLib APIs or calling code.
>
> I thought of that, but it would (I believe) introduce a dependency on 
> the MP protocol / PPI (for the WhoAmI() member), and that seems too 
> much for a base library like MtrrLib.
>
> I guess two new library instances could be created: one for PEIM and 
> another for DXE phase client modules. The MtrrLib functions could 
> check if the MP PPI / protocol were available. Negative answer: assume 
> we are running on the BSP, and debug-log away. Positive answer: call 
> WhoAmI(), and act accordingly.
>
> This would be usable -- I think -- for general thread-safety concerns, 
> not just debugging, but it's quite a bit of churn.
>
> ... Although, I'm not even fully sure whether (WhoAmI() == 0) can be 
> taken as "BSP". Given SwitchBSP() especially.
>
> Do you have better ideas for internally determining whether the 
> processor is an AP or a BSP? Something with the APIC IDs perhaps?
>
> Thanks
> Laszlo
>

There's the BSP flag (bit 8) in the MSR_IA32_APIC_BASE register.  It doesn't 
seem to be exposed nicely by BaseXApicX2ApicLib, but it's easy enough to read 
directly.
-- 

Brian J. Johnson



   My statements are my own, are not authorized by SGI, and do not
   necessarily represent SGI's positions.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v3 4/7] UefiCpuPkg/CpuMpPei/X64: Use CodeSegment and DataSegment fields

[Fan, Jeff]

Fixed typo: *add* whitespace. :-)

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fan, Jeff
Sent: Thursday, July 14, 2016 9:15 AM
To: Mudusuru, Giri P; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Tian, Feng
Subject: Re: [edk2] [Patch v3 4/7] UefiCpuPkg/CpuMpPei/X64: Use CodeSegment and 
DataSegment fields

Thanks! I will remove white space after "," in comments when commit.

-Original Message-
From: Mudusuru, Giri P
Sent: Wednesday, July 13, 2016 11:42 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Tian, Feng; Kinney, Michael D
Subject: RE: [Patch v3 4/7] UefiCpuPkg/CpuMpPei/X64: Use CodeSegment and 
DataSegment fields

Reviewed-by: Giri P Mudusuru <giri.p.mudus...@intel.com>

Please review and add white space after "," in comments during submission

> -Original Message-
> From: Fan, Jeff
> Sent: Tuesday, July 12, 2016 4:44 AM
> To: edk2-de...@ml01.01.org
> Cc: Tian, Feng <feng.t...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; Mudusuru, Giri P 
> <giri.p.mudus...@intel.com>
> Subject: [Patch v3 4/7] UefiCpuPkg/CpuMpPei/X64: Use CodeSegment and 
> DataSegment fields
> 
> Using CodeSegment and DataSegment fields in ExchangeInfo instead of 
> the hardcode MACROs for x64 arch. Switch AP from real mode to long 
> mode directly, so needn't the CS/DS of protected mode.
> 
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Giri Mudusuru <giri.p.mudus...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> ---
>  UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm  | 79 -
> ---
>  UefiCpuPkg/CpuMpPei/X64/MpFuncs.nasm | 67 +
> -
>  2 files changed, 62 insertions(+), 84 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm
> b/UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm
> index 1bb3b6d..57a995e 100644
> --- a/UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm
> +++ b/UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm
> @@ -1,5 +1,5 @@
>  
> ;-
> - ; -; Copyright (c) 2015, Intel Corporation. All rights 
> reserved.
> +; Copyright (c) 2015 - 2016, Intel Corporation. All rights 
> +reserved.
>  ; This program and the accompanying materials  ; are licensed and 
> made available under the terms and conditions of the BSD License  ; 
> which accompanies this distribution.  The full text of the license may 
> be found at @@ -47,25 +47,18 @@ RendezvousFunnelProcStart::
>  dw BufferStartLocation; movsi, BufferStartLocation
>  db 66h,  8Bh, 1Ch ; movebx,dword ptr [si]
> 
> -db 0BFh   ; opcode of mov di, mem16
> -dw PmodeOffsetLocation; movdi, PmodeOffsetLocation
> -db 66h,  8Bh, 05h ; moveax,dword ptr [di]
> -db 8Bh,  0F8h ; movdi, ax
> -db 83h,  0EFh,06h ; subdi, 06h
> -db 66h,  03h, 0C3h; addeax, ebx
> -db 66h,  89h, 05h ; movdword ptr [di],eax
> -
> -db 0BFh   ; opcode of mov di, mem16
> -dw LmodeOffsetLocation; movdi, LmodeOffsetLocation
> -db 66h,  8Bh, 05h ; moveax,dword ptr [di]
> -db 8Bh,  0F8h ; movdi, ax
> -db 83h,  0EFh,06h ; subdi, 06h
> -db 66h,  03h, 0C3h; addeax, ebx
> -db 66h,  89h, 05h ; movdword ptr [di],eax
> -
> -db 0BEh
> -dw Cr3Location; movsi, Cr3Location
> -db 66h,  8Bh, 0Ch ; movecx,dword ptr [si] ; 
> ECX is keeping
> the value of CR3
> +db 0BFh   ; opcode of mov di, mem16
> +dw LmodeOffsetLocation; movdi,  LmodeOffsetLocation
> +db 66h, 8Bh, 05h  ; moveax, [di]
> +db 0BFh   ; opcode of mov di, mem16
> +dw CodeSegmentLocation; movdi,  CodeSegmentLocation
> +db 66h, 8Bh, 15h  ; movedx, [di]
> +db 89h, 0C7h  ; movdi,  ax
> +db 83h, 0EFh, 02h ; subdi,  02h
> +db 89h, 15h   ; mov[di],dx; Patch 
> long mode CS
> +db 83h, 0EFh, 04h ; subdi,  04h
> +db 66h, 01h, 0D8h ; addeax, ebx
> +db 66h, 89h, 05h

Re: [edk2] [Patch v3 2/7] UefiCpuPkg/CpuMpPei/Ia32: Use CodeSegment and DataSegment fields

[Fan, Jeff]

Thanks! I will add one whitespace before eax in comments when commit.

-Original Message-
From: Mudusuru, Giri P 
Sent: Wednesday, July 13, 2016 11:21 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Tian, Feng; Kinney, Michael D
Subject: RE: [Patch v3 2/7] UefiCpuPkg/CpuMpPei/Ia32: Use CodeSegment and 
DataSegment fields

Reviewed-by: Giri P Mudusuru <giri.p.mudus...@intel.com>

Please add a whitespace before eax in the comments during submission.
mov[di],eax

> -Original Message-
> From: Fan, Jeff
> Sent: Tuesday, July 12, 2016 4:44 AM
> To: edk2-de...@ml01.01.org
> Cc: Tian, Feng <feng.t...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; Mudusuru, Giri P 
> <giri.p.mudus...@intel.com>
> Subject: [Patch v3 2/7] UefiCpuPkg/CpuMpPei/Ia32: Use CodeSegment and 
> DataSegment fields
> 
> Using CodeSegment and DataSegment fields in ExchangeInfo instead of 
> the hardcode MACROs.
> 
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Giri Mudusuru <giri.p.mudus...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> ---
>  UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.asm  | 38
> +--
>  UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.nasm | 28 ---
> ---
>  2 files changed, 40 insertions(+), 26 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.asm
> b/UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.asm
> index ab78bcc..c3a5a52 100644
> --- a/UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.asm
> +++ b/UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.asm
> @@ -1,5 +1,5 @@
>  
> ;-
> - ; -; Copyright (c) 2015, Intel Corporation. All rights 
> reserved.
> +; Copyright (c) 2015 - 2016, Intel Corporation. All rights 
> +reserved.
>  ; This program and the accompanying materials  ; are licensed and 
> made available under the terms and conditions of the BSD License  ; 
> which accompanies this distribution.  The full text of the license may 
> be found at @@ -51,13 +51,22 @@ RendezvousFunnelProcStart::
>  dw BufferStartLocation  ; movsi, BufferStartLocation
>  db 66h,  8Bh, 1Ch   ; movebx,dword ptr [si]
> 
> -db 0BFh ; opcode of mov di, mem16
> -dw PmodeOffsetLocation  ; movdi, PmodeOffsetLocation
> -db 66h,  8Bh, 05h   ; moveax,dword ptr [di]
> -db 8Bh,  0F8h   ; movdi, ax
> -db 83h,  0EFh,06h   ; subdi, 06h
> -db 66h,  03h, 0C3h  ; addeax, ebx
> -db 66h,  89h, 05h   ; movdword ptr [di],eax
> +db 0BEh ; opcode of mov si, mem16
> +dw PmodeOffsetLocation  ; movsi,  PmodeOffsetLocation
> +db 66h,  8Bh,  04h  ; moveax, [si]
> +db 0BEh ; opcode of mov si, mem16
> +dw CodeSegmentLocation  ; movsi,  CodeSegmentLocation
> +db 66h,  8Bh,  14h  ; movedx, [si]
> +db 89h, 0C7h; movdi,  ax
> +db 83h, 0EFh,  02h  ; subdi,  02h
> +db 89h,  15h; mov[di], dx
> +db 83h, 0EFh,  04h  ; subdi,  04h
> +db 66h,  01h, 0D8h  ; addeax, ebx
> +db 66h,  89h,  05h  ; mov[di],eax
> +
> +db 0BEh ; opcode of mov si, mem16
> +dw DataSegmentLocation  ; movsi,  DataSegmentLocation
> +db 66h,  8Bh,  14h  ; movedx, [si]
> 
>  db 0BEh ; opcode of mov si, mem16
>  dw GdtrLocation ; movsi, GdtrLocation
> @@ -78,15 +87,14 @@ RendezvousFunnelProcStart::
> 
>  db 66h,  67h, 0EAh  ; far jump
>  dd 0h   ; 32-bit offset
> -dw PROTECT_MODE_CS  ; 16-bit selector
> +dw 0h   ; 16-bit selector
> 
>  Flat32Start::   ; protected mode entry point
> -movax, PROTECT_MODE_DS
> -movds, ax
> -moves, ax
> -movfs, ax
> -movgs, ax
> -movss, ax
> +movds, dx
> +moves, dx
> +movfs, dx
> +movgs, dx
>

Re: [edk2] [PATCH v3 4/5] OvmfPkg: include UefiCpuPkg/CpuMpPei

[Fan, Jeff]

Reviewed-by: Jeff Fan <jeff@intel.com>

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, July 13, 2016 10:37 PM
To: edk2-devel-01
Cc: Fan, Jeff; Justen, Jordan L; Kinney, Michael D
Subject: [PATCH v3 4/5] OvmfPkg: include UefiCpuPkg/CpuMpPei

In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use.

CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond those 
already used by CpuDxe:

- PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these
  control whether CpuMpPei performs microcode update. If the region size
  is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the
  region size to zero by default, which is appropriate for OVMF.

- PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how
  CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait
  (with PAUSE). The latter PCD is only relevant if the former PCD is 2
  (MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself,
  we choose HLT. That's the default set by UefiCpuPkg.dec.

Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib 
technically, it is supposed to consume PeiCpuExceptionHandlerLib. See:

- http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703

- git commit a81abf161666 ("UefiCpuPkg/ExceptionLib: Import
  PeiCpuExceptionHandlerLib module"), part of the series linked above.

Jeff recommended to resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib 
for all PEIMs:

- http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477

Since at the moment we have no resolution in place that would cover this for 
PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]), it's easy 
to do.

Cc: Jeff Fan <jeff@intel.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Michael Kinney <michael.d.kin...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
---

Notes:
v3:
- resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib for all
  PEIMs [Jeff]
- drop Jeff's R-b from earlier

 OvmfPkg/OvmfPkgIa32.dsc| 5 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 5 +
 OvmfPkg/OvmfPkgX64.dsc | 5 +
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 6 files changed, 18 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 
805650059e96..8af326778205 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -212,6 +212,7 @@ [LibraryClasses.common.PEIM]  !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
 !endif
+  
+ CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCp
+ uExceptionHandlerLib.inf
 
 [LibraryClasses.common.DXE_CORE]
   HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -519,6 +520,10 @@ [Components]
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   }
 !endif
+  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
+
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+  }
 
   #
   # DXE Phase modules
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index 
7615ee96dff2..4bb38d0f7b3c 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -217,6 +217,7 @@ [LibraryClasses.common.PEIM]  !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
 !endif
+  
+ CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCp
+ uExceptionHandlerLib.inf
 
 [LibraryClasses.common.DXE_CORE]
   HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -527,6 +528,10 @@ [Components.IA32]
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   }
 !endif
+  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
+
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+  }
 
 [Components.X64]
   #
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index 
7f8a5c25a5c0..be3aa1fc6c43 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -217,6 +217,7 @@ [LibraryClasses.common.PEIM]  !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
 !endif
+  
+ CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCp
+ uExceptionHandlerLib.inf
 
 [LibraryClasses.common.DXE_CORE]
   HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -526,6 +527,10 @@ [Components]
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   }
 !endif
+  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
+
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+  }
 
   #
   # DXE Phase modules
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index 
ccc3e1461d55..136973443755 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -161,6 +161,7 @@ [FV.PEIFV]
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccessP

Re: [edk2] [Patch v3 4/7] UefiCpuPkg/CpuMpPei/X64: Use CodeSegment and DataSegment fields

[Fan, Jeff]

Thanks! I will remove white space after "," in comments when commit.

-Original Message-
From: Mudusuru, Giri P 
Sent: Wednesday, July 13, 2016 11:42 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Tian, Feng; Kinney, Michael D
Subject: RE: [Patch v3 4/7] UefiCpuPkg/CpuMpPei/X64: Use CodeSegment and 
DataSegment fields

Reviewed-by: Giri P Mudusuru <giri.p.mudus...@intel.com>

Please review and add white space after "," in comments during submission

> -Original Message-
> From: Fan, Jeff
> Sent: Tuesday, July 12, 2016 4:44 AM
> To: edk2-de...@ml01.01.org
> Cc: Tian, Feng <feng.t...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; Mudusuru, Giri P 
> <giri.p.mudus...@intel.com>
> Subject: [Patch v3 4/7] UefiCpuPkg/CpuMpPei/X64: Use CodeSegment and 
> DataSegment fields
> 
> Using CodeSegment and DataSegment fields in ExchangeInfo instead of 
> the hardcode MACROs for x64 arch. Switch AP from real mode to long 
> mode directly, so needn't the CS/DS of protected mode.
> 
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Giri Mudusuru <giri.p.mudus...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> ---
>  UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm  | 79 -
> ---
>  UefiCpuPkg/CpuMpPei/X64/MpFuncs.nasm | 67 +
> -
>  2 files changed, 62 insertions(+), 84 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm
> b/UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm
> index 1bb3b6d..57a995e 100644
> --- a/UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm
> +++ b/UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm
> @@ -1,5 +1,5 @@
>  
> ;-
> - ; -; Copyright (c) 2015, Intel Corporation. All rights 
> reserved.
> +; Copyright (c) 2015 - 2016, Intel Corporation. All rights 
> +reserved.
>  ; This program and the accompanying materials  ; are licensed and 
> made available under the terms and conditions of the BSD License  ; 
> which accompanies this distribution.  The full text of the license may 
> be found at @@ -47,25 +47,18 @@ RendezvousFunnelProcStart::
>  dw BufferStartLocation; movsi, BufferStartLocation
>  db 66h,  8Bh, 1Ch ; movebx,dword ptr [si]
> 
> -db 0BFh   ; opcode of mov di, mem16
> -dw PmodeOffsetLocation; movdi, PmodeOffsetLocation
> -db 66h,  8Bh, 05h ; moveax,dword ptr [di]
> -db 8Bh,  0F8h ; movdi, ax
> -db 83h,  0EFh,06h ; subdi, 06h
> -db 66h,  03h, 0C3h; addeax, ebx
> -db 66h,  89h, 05h ; movdword ptr [di],eax
> -
> -db 0BFh   ; opcode of mov di, mem16
> -dw LmodeOffsetLocation; movdi, LmodeOffsetLocation
> -db 66h,  8Bh, 05h ; moveax,dword ptr [di]
> -db 8Bh,  0F8h ; movdi, ax
> -db 83h,  0EFh,06h ; subdi, 06h
> -db 66h,  03h, 0C3h; addeax, ebx
> -db 66h,  89h, 05h ; movdword ptr [di],eax
> -
> -db 0BEh
> -dw Cr3Location; movsi, Cr3Location
> -db 66h,  8Bh, 0Ch ; movecx,dword ptr [si] ; 
> ECX is keeping
> the value of CR3
> +db 0BFh   ; opcode of mov di, mem16
> +dw LmodeOffsetLocation; movdi,  LmodeOffsetLocation
> +db 66h, 8Bh, 05h  ; moveax, [di]
> +db 0BFh   ; opcode of mov di, mem16
> +dw CodeSegmentLocation; movdi,  CodeSegmentLocation
> +db 66h, 8Bh, 15h  ; movedx, [di]
> +db 89h, 0C7h  ; movdi,  ax
> +db 83h, 0EFh, 02h ; subdi,  02h
> +db 89h, 15h   ; mov[di],dx; Patch 
> long mode CS
> +db 83h, 0EFh, 04h ; subdi,  04h
> +db 66h, 01h, 0D8h ; addeax, ebx
> +db 66h, 89h, 05h  ; mov[di],eax   ; Patch 
> address
> 
>  db 0BEh   ; opcode of mov si, mem16
>  dw GdtrLocation   ; movsi, GdtrLocation
> @@ -77,48 +70,44 @@ RendezvousFunnelProcStart::
>  db 66h; db 66h
>  db 2Eh,0Fh, 01h, 1Ch 

Re: [edk2] [Patch] UefiCpuPkg/CpuDxe: StartupAllAPs in parallel mode

[Fan, Jeff]

Laszlo,

I think of it. We could just remove the MtrrDebugPrintAllMtrrs() call from 
MtrrSetAllMtrrs() implementation in MtrrLib.

The reason is that Aps' MTRR settings should be always same with the BPS's. BSP 
will set the MTRRs setting by MtrrSetMemoryAttribute() or other APIs. And Aps 
will always sync the whole MTRRs setting by MtrrSetAllMtrrs(). 

MtrrSetMemoryAttribute() or other  APIs will display all MTRRs setting after 
MTRRs setting changed. That means we could get the latest MTRRs setting when 
BSP updated MTRR setting.

We needn't MtrrSetAllMtrrs() to dump all MTRRs setting again. The MTRRs output 
message is duplicated.

After removed MtrrDebugPrintAllMtrrs() call from MtrrSetAllMtrrs() and enabled 
EFI_D_CACHE flag. I can see the updated MTRR setting and no debug message 
output from Aps.

I could create the patch on MtrrLib to address this issue. 

Thanks!
Jeff 

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, July 08, 2016 5:45 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Tian, Feng
Subject: Re: [Patch] UefiCpuPkg/CpuDxe: StartupAllAPs in parallel mode

On 07/08/16 10:59, Fan, Jeff wrote:
> Laszlo,
> 
> Thanks your feedback and provided the history on MTRRs sync code.
> 
> DEBUG () running on Aps is a common issue to be avoided.
> For MtrrLib, DEBUG() is using DEBUG_CACHE for debug purpose only.
> Usually, MTRRs setting should be same between BSP/Aps. Dump MTRRs are 
> enough for BSP. Maybe, we could enhance MtrrLib to avoid DEBUG () 
> running on Aps.

That's a good idea! Maybe we can sneak in some context so that
MtrrDebugPrintAllMtrrsWorker() knows it is running on an AP, and omits debug 
logging.

> For the case 2) in StartupAllAPs() call in InitializeMpSupport(), it 
> will be handled in our refactor on MP support between CpuMpPei and 
> CpuDxe driver as Mike mentioned. I wish we could sent out MP Initial 
> Lib support in a couple of weeks.

Sounds great!
Thanks!
Laszlo

> 
> Thanks!
> Jeff
> 
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, July 08, 2016 4:38 PM
> To: Fan, Jeff; edk2-de...@ml01.01.org
> Cc: Kinney, Michael D; Tian, Feng
> Subject: Re: [Patch] UefiCpuPkg/CpuDxe: StartupAllAPs in parallel mode
> 
> Jeff,
> 
> On 07/08/16 09:45, Jeff Fan wrote:
>> SetMemoryAttributes() will sync BSP's MTRRs settings to all APs by 
>> StartupAllAPs service in serial mode. It may caused much performance 
>> impact if there are too much processors in system. This update is to 
>> invoke StartupAllAps in parallel mode. IA32 SDM does suggest to program 
>> MTRRs in parallel mode.
>>
>> Cc: Michael Kinney <michael.d.kin...@intel.com>
>> Cc: Feng Tian <feng.t...@intel.com>
>> Cc: Laszlo Ersek <ler...@redhat.com>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Jeff Fan <jeff@intel.com>
>> Reviewed-by: Feng Tian <feng.t...@intel.com>
>> ---
>>  UefiCpuPkg/CpuDxe/CpuDxe.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c 
>> index daf97bd..78b2c88 100644
>> --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
>> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
>> @@ -1,7 +1,7 @@
>>  /** @file
>>CPU DXE Module.
>>  
>> -  Copyright (c) 2008 - 2013, Intel Corporation. All rights 
>> reserved.
>> +  Copyright (c) 2008 - 2016, Intel Corporation. All rights 
>> + reserved.
>>This program and the accompanying materials
>>are licensed and made available under the terms and conditions of the BSD 
>> License
>>which accompanies this distribution.  The full text of the license 
>> may be found at @@ -422,7 +422,7 @@ CpuSetMemoryAttributes (
>>MpStatus = MpService->StartupAllAPs (
>>MpService,  // This
>>SetMtrrsFromBuffer, // Procedure
>> -  TRUE,   // SingleThread
>> +  FALSE,  // SingleThread
>>NULL,   // WaitEvent
>>0,  // TimeoutInMicrosecsond
>>,  // ProcedureArgument
>>
> 
> (1) This change looks "obvious" on the surface, and to be honest, when 
> looking at your patch now, I couldn't tell for a minute what I was thinking 
> when I set SingleThread=TRUE, in commit 94941c8853448.
> 
> Digging down a bit, I believe I remember now. The APs execute the following 
> call chain:
> 
> SetMtrrsFromBuffer()  

Re: [edk2] [Patch] UefiCpuPkg/MtrrLib: Remove MTRRs display from MtrrSetAllMtrrs()

[Fan, Jeff]

Laszlo,

Yes. You are correct. MtrrSetAllMtrrs() could be used by BSP to make whole MTRR 
updating. 
I agree this patch will be feature drop on MtrrSetAllMtrrs() on MTRR setting 
display.

I reviewed the example you listed.
- OvmfPkg/PlatformPei/MemDetect.c-- MTRR setting will be displayed in 
MtrrSetMemoryAttribute() invoking after MtrrSetAllMtrrs() invoked.

- UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c -- The MTRR setting is saved in normal boot 
path and should have been displayed in normal boot already.

- Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c -- This is the case you 
suggested to invoke MtrrDebugPrintAllMtrrs() explicitly. This is also what I 
suggested.

And I agree we need to state some services are not safe for Aps. But I am not 
sure if we need to add this notes in UefiCpuPkg/Include/Library/MtrrLib.h. 
Because this is just limitation of MtrrLib instance implementation.
Maybe, we could add this note in UefiCpuPkg/Library/MtrrLib/MtrrLib.c.

How do you think it?

Thanks!
Jeff

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Wednesday, July 13, 2016 2:21 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Tian, Feng
Subject: Re: [edk2] [Patch] UefiCpuPkg/MtrrLib: Remove MTRRs display from 
MtrrSetAllMtrrs()

On 07/13/16 02:33, Jeff Fan wrote:
> MtrrSetAllMtrrs() maybe used by APs to sync BSP's MTRR settings. BSP's 
> MTRR setting should be displayed if EFI_D_CACHE flag is set when MTRR 
> updated. In MtrrSetAllMtrrs(), it's not necessary to display MTRR 
> setting again due to the MTRR settings should be always same among 
> BSP/APs. This updating could avoid APs output MTRR setting at the same time 
> and make display message corrupted.
> 
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> ---
>  UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
> b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> index 6a6bf76..f667a8f 100644
> --- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> +++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
> @@ -2103,8 +2103,6 @@ MtrrSetAllMtrrs (
>  
>PostMtrrChangeEnableCache ();
>  
> -  MtrrDebugPrintAllMtrrs ();
> -
>return MtrrSetting;
>  }
>  
> 

I think I must have misunderstood your previous email about this -- I apologize 
for that!

I realize now that you meant that the BSP is expected to set up its MTRRs using 
other APIs *only*. Those APIs would still print the MTRR settings (with 
EFI_D_CACHE) and then it would not be necessary for the APs to print the same 
settings with MtrrSetAllMtrrs().

Unfortunately, MtrrSetAllMtrrs() is used by the BSP as well, for setting up its 
MTRRs from the scratch. Some examples:

- OvmfPkg/PlatformPei/MemDetect.c -- setting up the initial MTRRs
- UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c -- this restores MTRRs on S3, and
  the BSP also uses MtrrSetAllMtrrs() for that
- Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c -- I'm not very
  familiar with this module, but it seems to invoke MtrrSetAllMtrrs()
  on the BSP too

So I think restricting MtrrSetAllMtrrs() to APs only would be an incompatible 
change for this library. I apologize again for wasting your time by 
misunderstanding your previous email. :(

* I propose the following:
- introduce a new library class interface that does the same as
  MtrrSetAllMtrrs(), but takes an additional BOOLEAN parameter called
  ThreadSafe
- update the "UefiCpuPkg/Include/Library/MtrrLib.h" library class
  header to state that the library interfaces are unsafe for being
  called from APs, *except* the new function, when ThreadSafe=TRUE
- the MtrrSetAllMtrrs() function would be specified to be equivalent to
  the new function with ThreadSafe=FALSE
- implement the new function for the single library instance that
  exists now. The implementation wouldn't be hard -- if ThreadSafe, then
  omit MtrrDebugPrintAllMtrrs().
- Audit all current uses of MtrrSetAllMtrrs(), and whenever it is
  called from an AP, change it to the new library API, with
  ThreadSafe=TRUE.

Now I realize you could consider this a lot of work for nothing, so I don't 
"insist" :) Here's an alternative suggestion (should be much easier):

* I just noticed that MtrrDebugPrintAllMtrrs() is a library class API!
It's not an internal-only function. That's great; it allows the following:
- include this patch in the series, as is -- patch #1
- update the "UefiCpuPkg/Include/Library/MtrrLib.h" library class
  header to state that the library interfaces are unsafe for being
  called from APs, *except* MtrrDebugPrintAllMtrrs() -- patch #2
- Audit all current uses 

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: SMM_CPU_DATA_BLOCK is not cleared

[Fan, Jeff]

Laszlo,

Yes. We hit the issue at normal boot on some platform.

I agree we could update comments to mention the CandidateBsp array of BOOLEANs 
also.

Thanks!
Jeff
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, July 19, 2016 7:25 PM
To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-de...@ml01.01.org; 
Fan, Jeff <jeff@intel.com>
Cc: Tian, Feng <feng.t...@intel.com>
Subject: Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: SMM_CPU_DATA_BLOCK is 
not cleared

On 07/19/16 04:58, Michael Kinney wrote:
> From: Jeff Fan <jeff@intel.com>
> 
> The commit 8b9311 changed the zeroing of mSmmMpSyncData of type 
> SMM_DISPATCHER_MP_SYNC_DATA by the following patch.
>  -ZeroMem (mSmmMpSyncData, mSmmMpSyncDataSize);
>  +mSmmMpSyncData->SwitchBsp = FALSE;
> 
> mSmmMpSyncDataSize not only includes SMM_DISPATCHER_MP_SYNC_DATA, but 
> also includes the SMM_CPU_DATA_BLOCK array and one BOOLEAN variable 
> array as shown here:
> 
>   mSmmMpSyncDataSize = sizeof (SMM_DISPATCHER_MP_SYNC_DATA) +
>(sizeof (SMM_CPU_DATA_BLOCK) + sizeof (BOOLEAN)) *
>gSmmCpuPrivate->SmmCoreEntryContext.NumberOfCpus;
> 
> This patch restores the original ZeroMem() to clear all CPU Sync data. 
> The commit 8b9311 may cause unexpected behavior.
> 
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 5ba0514..fe9076b 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -1276,7 +1276,10 @@ InitializeMpSyncData (
>UINTN  CpuIndex;
>  
>if (mSmmMpSyncData != NULL) {
> -mSmmMpSyncData->SwitchBsp = FALSE;
> +//
> +// mSmmMpSyncDataSize includes SMM_DISPATCHER_MP_SYNC_DATA and 
> SMM_CPU_DATA_BLOCK range
> +//
> +ZeroMem (mSmmMpSyncData, mSmmMpSyncDataSize);
>  mSmmMpSyncData->CpuData = (SMM_CPU_DATA_BLOCK *)((UINT8 *)mSmmMpSyncData 
> + sizeof (SMM_DISPATCHER_MP_SYNC_DATA));
>  mSmmMpSyncData->CandidateBsp = (BOOLEAN *)(mSmmMpSyncData->CpuData + 
> gSmmCpuPrivate->SmmCoreEntryContext.NumberOfCpus);
>  if (FeaturePcdGet (PcdCpuSmmEnableBspElection)) {
> 

* Am I right to think that this issue can hit on the normal boot path as well, 
if the pages allocated by InitializeSmmCpuSemaphores() for this area were 
allocated and released earlier, by another part of the firmware?

Given that this area is allocated from SMRAM, the above should be pretty 
unlikely though. Are you experiencing the issue at S3 resume only, or even on 
normal boot? Are there any special circumstances that trigger it?

I'm trying to gauge if this is a severe bug that should be backported to our 
downstream OVMF package "urgently", or if it's okay to get the patch 
"eventually" (when we next rebase). We haven't seen the issue in practice.

* Second, this patch makes me remember

229fd9e7aa1c MdeModulePkg: PiSmmCore: Remove confusing CopyMem()
 of _ENTRY_CONTEXT

Namely, I wonder if it would be clearer to zero out mSmmMpSyncData,
mSmmMpSyncData->CpuData, and mSmmMpSyncData->CandidateBsp separately.

OTOH, if a new array of some sort was appended, then that would need separate 
zeroing again, which is easy to forget -- mSmmMpSyncDataSize is pretty clear 
and robust against further field additions.

So I think my only suggestion is to change the comment:

//
// mSmmMpSyncDataSize includes SMM_DISPATCHER_MP_SYNC_DATA and // other data 
packed after it //

This is motivated by two facts:
- the comment is already inaccurate, because it doesn't mention the
  CandidateBsp array of BOOLEANs
- should another field be appended later on, the comment would remain
  valid

The point is that we should warn the reader that mSmmMpSyncDataSize bytes have 
to be cleared, because there are "other data" after what's apparent. What do 
you think?

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 1/4] UefiCpuPkg/CpuDxe: StartupAllAPs in parallel mode

[Fan, Jeff]

Laszlo,

Good suggestion! I could exchange the commit order of Patch 1/4 and Patch 2/4.

Thanks!
Jeff
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, July 19, 2016 6:48 PM
To: Fan, Jeff <jeff@intel.com>; edk2-de...@ml01.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Tian, Feng 
<feng.t...@intel.com>
Subject: Re: [edk2] [Patch 1/4] UefiCpuPkg/CpuDxe: StartupAllAPs in parallel 
mode

On 07/19/16 02:57, Jeff Fan wrote:
> SetMemoryAttributes() will sync BSP's MTRRs settings to all APs by 
> StartupAllAPs service in serial mode. It may caused much performance 
> impact if there are too much processors in system. This update is to 
> invoke StartupAllAps in parallel mode. IA32 SDM does suggest to program MTRRs 
> in parallel mode.
> 
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff@intel.com>
> Reviewed-by: Feng Tian <feng.t...@intel.com>
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c 
> index daf97bd..78b2c88 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
> @@ -1,7 +1,7 @@
>  /** @file
>CPU DXE Module.
>  
> -  Copyright (c) 2008 - 2013, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2008 - 2016, Intel Corporation. All rights 
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
>which accompanies this distribution.  The full text of the license 
> may be found at @@ -422,7 +422,7 @@ CpuSetMemoryAttributes (
>MpStatus = MpService->StartupAllAPs (
>MpService,  // This
>SetMtrrsFromBuffer, // Procedure
> -  TRUE,   // SingleThread
> +  FALSE,  // SingleThread
>NULL,   // WaitEvent
>0,  // TimeoutInMicrosecsond
>,  // ProcedureArgument
> 

For the patch itself:

Reviewed-by: Laszlo Ersek <ler...@redhat.com>

I think it would be preferable to reverse the order of patch #2 and patch #1 in 
this series, so that when you flip the above to multi-threaded, the library 
instance is already safe to use like that.

This reordering can be done before you commit the patches, of course.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel