Re: [edk2] BaseTools features: multiple workspaces

[Kinney, Michael D]

Jordan,

We already have EDK_TOOLS_PATH for the path to the tools, so I don't think we 
should add WORKSPACE_TOOLS.

The DSC file specifies the output directory and the syntax supports both 
workspace relative paths and absolute paths.  I am not sure I understand what 
issue is addressed by adding WORKSPACE_BUILD.  If DSC specifies output 
directory using a workspace relative path, then tools use WORKSPACE.  If DSC 
uses absolute path for the output path, then the output can be places anywhere. 
 

The build command supports the --conf flag, so alternate CONF directories can 
be specified on the build command line.  I am not sure I understand what issue 
is addressed by adding WORKSPACE_CONF.

Best regards,

Mike

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
Justen
Sent: Wednesday, August 05, 2015 12:09 PM
To: Gao, Liming; Laszlo Ersek
Cc: Paolo Bonzini; edk2-devel@lists.01.org
Subject: Re: [edk2] BaseTools features: multiple workspaces

On 2015-08-05 07:06:46, Gao, Liming wrote:
 Thanks for your all comments. 
 
 Most people prefers to keep WOSKAPCE as single directory, and
 introduce new env $(WORKSPACE_MULTIPLE).

I'm not sure about this conclusion. I think Paolo, Laszlo and I all
expressed that using WORKSPACE for the multiple directories seemed
more natural.

I think you originally suggested just using WORKSPACE, but maybe now
have changed your mind.

I know Tim had some big concerns with expanding WORKSPACE. I agree
with his concerns, but I don't think it will be much better with
WORKSPACE_MULTIPLE. (The same tools will break.)

Mike and Andrew appear to prefer WORKSPACE_MULTIPLE.

What about this suggestion?

WORKSPACE: expand to a list of directories

WORKSPACE_BUILD: if not set, use first path in WORKSPACE + '/Build'

WORKSPACE_CONF: if not set, scan WORKSPACE paths to find 'Conf' dir

WORKSPACE_TOOLS: if not set, scan WORKSPACE paths to find 'BaseTools' dir

With WORKSPACE and WORKSPACE_MULTIPLE we have a strange intersection
of 'part of the source tree' and 'all of the source tree'. I think the
variables I recommend avoid that partial overlap.

-Jordan

 I think Mike solution can
 make them more clear if WORKSPACE_MULTIPLE is set.
 
 On QA team impact, it should be small. QA team can still use the
 current working model to place all packages in root directory, and
 set WORKSPACE only. QA team just needs to know the package list.
 
 Tim gave another idea to define multiple source locations in
 Platform DSC file. It doesn't conflict with this proposal. We can
 implement $(WORKSPACE_MULTIPLE) feature first, and evaluate DSC
 update. On the fixed tree layout, these two solutions can work. Once
 the end user reorganizes its tree layout, he needs to set
 $(WORKSPACE_MULTIPLE) env or update Platform DSC file, and build
 platform DSC.
 
 Thanks
 Liming
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com] 
 Sent: Tuesday, August 04, 2015 7:20 PM
 To: Justen, Jordan L
 Cc: Gao, Liming; Paolo Bonzini; edk2-devel@lists.01.org
 Subject: Re: [edk2] BaseTools features: multiple workspaces
 
 On 08/03/15 19:35, Jordan Justen wrote:
  On 2015-08-03 02:08:14, Gao, Liming wrote:
  Paolo:
I think that keep the exiting syntax for WORKSPACE to be a single
path can minimize the impacts to exiting tools that assume a
single workspace.
  
  I know you originally suggested to use WORKSPACE, but got some 
  feedback that it might be better to create a new variable to not break 
  some unspecified tools.
  
  Was anyone able to name an actual tool that would be impacted? Why not 
  work to update these tools at the same time? An easy 'fix' will be for 
  any such tool to give an error message if it sees ':' or ';' in the 
  WORKSPACE environment variable. Although this is really not a fix, it 
  will be just as much support as if they ignore the new 
  WORKSPACE_MULTIPLE environment variable.
  
  I think that using the single separated WORKSPACE environment variable 
  is more intuitive/expected. From using env vars such as PATH, we all 
  know what it means.
  
  For WORKSPACE+WORKSPACE_MULTIPLE, I don't know which has priority. I 
  assume WORKSPACE is checked first, and then WORKSPACE_MULTIPLE?
 
 This was described in Liming's email, in point 4b.
 
  
  Will this work for the integrated CryptoPkg + open-ssl? It seems like 
  we need a priority above EDK II for this. I guess WORKSPACE will not 
  be set to EDK II in this case?
  
  Anyway, it just seems a little odd.
 
 For me a colon-separated (well, separator-separated :)) single WORKSPACE 
 variable would be more intuitive, but WORKSPACE_MULTIPLE can be defined well 
 enough too. For example:
 - WORKSPACE must not contain separators
 - if WORKSPACE_MULTIPLE is set, then the effect is as if
   ${WORKSPACE}:${WORKSPACE_MULTIPLE} were specified under the
   well-known PATH semantics.
 
 No clue about the CryptoPkg impact. Can you remind me please why CryptoPkg / 
 OpensslLib 

Re: [edk2] BaseTools features: multiple workspaces

[Kinney, Michael D]

Jordan,

If we make a slight change to the requirements, we can provide clear priority 
rules.

WORKSPACE is used to find Build and Conf.

If WORKSPACE_MULTIPLE exists, then it is used as a prioritized list of paths to 
resolve all other workspace relative paths.  This means WORKSPACE_MULTIPLE will 
need to also contain that path to WORKSPACE as one of its path if WORKSPACE has 
packages in it too.  This means rule 4b needs to be adjusted.

Mike

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
Justen
Sent: Monday, August 03, 2015 11:55 AM
To: Tim Lewis; Gao, Liming; Paolo Bonzini
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] BaseTools features: multiple workspaces

Cc: edk2-devel

On 2015-08-03 10:41:43, Tim Lewis wrote:
 There are dozens of tools in commercial environments (including some
 by Insyde) which will fail in this case. In addition, there are
 codebases that I am aware of where $(WORKSPACE) is allowed directly
 in other build files.

Will all these 'dozens of tools in commercial environments' fare any
better with the WORKSPACE_MULTIPLE option?

As a quick example, say C:\ssl\CryptoPkg has open-ssl integrated, and
C:\edk2 is the plain EDK II tree.

Thus, we want to set WORKSPACE=C:\ssl and WORKSPACE_MULTIPLE=C:\edk2
so the open-ssl integrated version of CryptoPkg will take priority.

Are these tools likely to work as expected? I am guessing no. I'm
thinking that these tools will probably have to insist on a fully
integrated single workspace until they can be updated to the new
design.

At that point whether WORKSPACE can have multiple directories, or we
add WORKSPACE_MULTIPLE, it will not make a big difference to these
tools.

-Jordan

 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
 Justen
 Sent: Monday, August 03, 2015 10:36 AM
 To: Gao, Liming liming@intel.com; Paolo Bonzini pbonz...@redhat.com; 
 edk2-devel@lists.01.org
 Subject: Re: [edk2] BaseTools features: multiple workspaces
 
 On 2015-08-03 02:08:14, Gao, Liming wrote:
  Paolo:
I think that keep the exiting syntax for WORKSPACE to be a single
path can minimize the impacts to exiting tools that assume a
single workspace.
 
 I know you originally suggested to use WORKSPACE, but got some feedback that 
 it might be better to create a new variable to not break some unspecified 
 tools.
 
 Was anyone able to name an actual tool that would be impacted? Why not work 
 to update these tools at the same time? An easy 'fix' will be for any such 
 tool to give an error message if it sees ':' or ';' in the WORKSPACE 
 environment variable. Although this is really not a fix, it will be just as 
 much support as if they ignore the new WORKSPACE_MULTIPLE environment 
 variable.
 
 I think that using the single separated WORKSPACE environment variable is 
 more intuitive/expected. From using env vars such as PATH, we all know what 
 it means.
 
 For WORKSPACE+WORKSPACE_MULTIPLE, I don't know which has priority. I assume 
 WORKSPACE is checked first, and then WORKSPACE_MULTIPLE?
 
 Will this work for the integrated CryptoPkg + open-ssl? It seems like we need 
 a priority above EDK II for this. I guess WORKSPACE will not be set to EDK II 
 in this case?
 
 Anyway, it just seems a little odd.
 
 -Jordan
 
  -Original Message-
  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
  Paolo Bonzini
  Sent: Monday, August 03, 2015 4:31 PM
  To: Gao, Liming; edk2-devel@lists.01.org
  Subject: Re: [edk2] BaseTools features: multiple workspaces
  
  
  On 03/08/2015 05:56, Gao, Liming wrote:
   Hi, all
 We will update BaseTools feature to allow more than one workspaces. The 
   detail design in the below. Please help review it. If you have any 
   comments, please let me know.
   
   1.   Keep $(WORKSPACE) environment as is
   
   a.   $(WORKSPACE) determines location of Build and Conf directory.
   
   2.   New optional $(WORKSPACE_MULTIPLE) environment is added to 
   include more directories with the separator ';', like $(PATH)
  
  Why is $(WORKSPACE_MULTIPLE) necessary?  On Linux it is okay to break 
  preexisting paths that contain a :; on Windows semicolons are allowed in 
  theory but in practice break in several ways.
  
  Paolo
  
   a.   Produce the same behavior if $(WORKSPACE_MULTIPLE) is not set.
   
   3.   Update edksetup.bat/edksetup.sh to find BaseTools directory from 
   $(WORKSPACE) and $(WORKSPACE_MULTIPLE) directories.
   
   4.   Update BaseTools to support multiple workspaces
   
   a.   For the relative file path (INF, DSC and FDF), BaseTools will 
   search them from $(WORKSPACE) and $(WORKSPACE_MULTIPLE) directories.
   
   b.  Search priority from high to low: $(WORKSPACE), 
   $(WORKSPACE_MULTIPLE).
   
   This is a compatible feature. It has no impact on current EDKII 
   project.
  ___
  

Re: [edk2] [PATCH] UefiCpuPkg: PiSmmCpuDxeSmm: Remove unused references to SmmLib

[Kinney, Michael D]

Laszlo,

I updated the message with your suggestion.

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Thursday, October 22, 2015 3:44 AM
>To: Kinney, Michael D; edk2-de...@ml01.01.org
>Cc: Yao, Jiewen; Fan, Jeff
>Subject: Re: [edk2] [PATCH] UefiCpuPkg: PiSmmCpuDxeSmm: Remove unused
>references to SmmLib
>
>Mike,
>
>On 10/22/15 01:25, Michael Kinney wrote:
>> The PiSmmCpuDxeSmm module does not use any services from the SmmLib.
>> This change removes the SmmLib from PiSmmCpuDxeSmm module and also
>> removes the lib mapping in the UefiCpuPkg DSC file because no other
>> modules in the UefiCpuPkg use the SmmLib.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
>> CC: Yao, Jiewen <jiewen@intel.com>
>> CC: Jeff Fan <jeff@intel.com>
>> ---
>>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   | 1 -
>>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 1 -
>>  UefiCpuPkg/UefiCpuPkg.dsc| 1 -
>>  3 files changed, 3 deletions(-)
>
>If you have not committed this patch yet, please consider updating the
>commit message to state: removal of SmmLib is now possible because the
>only API call to it, ClearSmi(), was ultimately removed from
>PiSmmCpuDxeSmm -- see the "BUGBUG" comment in git commit 529a5a86.
>
>Thanks!
>Laszlo
>
>>
>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
>b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
>> index 9ea1189..162bdad 100644
>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
>> @@ -30,7 +30,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
>KIND, EITHER EXPRESS OR IMPLIED.
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
>b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
>> index 45ab16c..f559947 100644
>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
>> @@ -101,7 +101,6 @@
>>SynchronizationLib
>>BaseMemoryLib
>>MtrrLib
>> -  SmmLib
>>IoLib
>>TimerLib
>>SmmServicesTableLib
>> diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
>> index 10197d4..756645f 100644
>> --- a/UefiCpuPkg/UefiCpuPkg.dsc
>> +++ b/UefiCpuPkg/UefiCpuPkg.dsc
>> @@ -55,7 +55,6 @@
>>
>SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchroniza
>tionLib.inf
>>SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
>>
>CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCache
>MaintenanceLib.inf
>> -  SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
>>PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf
>>PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
>>
>SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/
>SmmCpuPlatformHookLibNull.inf
>>
>
>___
>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] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

[Kinney, Michael D]

Laszlo,

Thanks for the very detailed and complete root cause on this issue.  I agree 
that the change you suggest is functional, but I am going to recommend a 
different solution.

Unfortunately, there are several modules that set up a GDT and it is easier 
from an implementation perspective and for debugging if all the modules agree 
to use the same GDT layout.  It would be even better if no modules make any 
assumptions about GDT layouts, but that is a bigger change that we can tackle 
later.

The root cause of this specific issue is that the GDT that is set up by 
MdeModulePkg/Core/DxeIplPeim is not the same GDT that is set up by UefiCpuPkg 
/CpuDxe.  And the UefiCpuPkg/PiSmmCpuDxeSmm module has some assumptions that 
the GDT is the one setup by MdeModulePkg/Core/DxeIplPeim.  I recommend we 
update UefiCpuPkg/CpuDxe to use the same GDT layout as 
MdeModulePkg/Core/DxeIplPeim and then the changes you found worked for 
PiSmmCpuDxeSmm are not required.

I will work on a patch for you to test.

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Thursday, October 29, 2015 9:19 AM
>To: Yao, Jiewen; Kinney, Michael D; Fan, Jeff
>Cc: Justen, Jordan L; edk2-devel-01
>Subject: Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in
>S3Resume2Pei
>
>Hi Jiewen,
>
>On 10/29/15 03:28, Yao, Jiewen wrote:
>> Thanks for the info. I think we might have to dig out why LONG_JUMP fail
>here.
>> Most our IA BIOS support Ia32X64 mode, so I am sure it should work.
>
>I think I have found the bug.
>
>(1)
>I added a debug patch to OvmfPkg/QuarkPort/CpuS3DataDxe. I'm attaching it
>for illustration. The debug patch dumps the following information:
>- the location of the GDT descriptor (that gets loaded into the GDT register)
>- the contents of the GDT descriptor (i.e., the base and limit of the global
>descriptor table)
>- the contents of the GDT entries (the individual segment descriptors)
>
>CpuS3DataDxe saves these in AcpiNVS. Later they are saved by
>PiSmmCpuDxeSmm from AcpiNVS to SMRAM (during boot), and then restored
>from SMRAM to AcpiNVS (during S3 Resume).
>
>The patch dumps these details when the preparation for PiSmmCpuDxeSmm,
>in AcpiNVS, is ready.
>
>Here's the debug output:
>
>SaveCpuS3Data: 350: GDT descriptor at 0x7E3E2050
>SaveCpuS3Data: 353: GDT Base=0x7F706000 Limit=0x3F
>SaveCpuS3Data: 363: Idx=0x00 Base=0x Limit=0x Type=0x0
>System=0x0 Dpl=0x0 Present=0x0 Software=0x0 LCodeSeg=0x0 DefaultSize=0x0
>SaveCpuS3Data: 363: Idx=0x08 Base=0x Limit=0x Type=0x3
>System=0x1 Dpl=0x0 Present=0x1 Software=0x0 LCodeSeg=0x0 DefaultSize=0x1
>SaveCpuS3Data: 363: Idx=0x10 Base=0x Limit=0x Type=0xB
>System=0x1 Dpl=0x0 Present=0x1 Software=0x0 LCodeSeg=0x0 DefaultSize=0x1
>SaveCpuS3Data: 363: Idx=0x18 Base=0x Limit=0x Type=0x2
>System=0x1 Dpl=0x0 Present=0x1 Software=0x0 LCodeSeg=0x0 DefaultSize=0x1
>SaveCpuS3Data: 363: Idx=0x20 Base=0x Limit=0x Type=0xA
>System=0x1 Dpl=0x0 Present=0x1 Software=0x0 LCodeSeg=0x0 DefaultSize=0x1
>SaveCpuS3Data: 363: Idx=0x28 Base=0x Limit=0x Type=0xB
>System=0x1 Dpl=0x0 Present=0x1 Software=0x0 LCodeSeg=0x1 DefaultSize=0x0
>SaveCpuS3Data: 363: Idx=0x30 Base=0x Limit=0x Type=0x0
>System=0x0 Dpl=0x0 Present=0x0 Software=0x0 LCodeSeg=0x0 DefaultSize=0x0
>SaveCpuS3Data: 363: Idx=0x38 Base=0x Limit=0x Type=0x0
>System=0x0 Dpl=0x0 Present=0x0 Software=0x0 LCodeSeg=0x0 DefaultSize=0x0
>
>(Importantly, the debug output is identical between the pure Ia32 build and
>the Ia32X64 build, except the addresses in the first two lines -- the location 
>of
>the GDT descriptor, and the location of the GDT itself.)
>
>
>(2) Now locate the offset (= selector) of the *only* segment that is advertised
>as "64-bit code". The LCodeSeg bit-field is 1 only for Idx=0x28.
>
>
>(3) If you examine "UefiCpuPkg/PiSmmCpuDxeSmm/X64/MpFuncs.asm", you
>can see:
>
>LONG_JUMP::
>
>db 67h,  0EAh ; far jump
>dd 0h ; 32-bit offset
>dw 38h; 16-bit selector
>
>The segment selector is 0x38 here, which not only lacks the LCodeSeg (= long
>mode code) bit, but it is actually a null-descriptor.
>
>So this is the direct cause for the triple fault, but why does it work in the 
>pure
>Ia32 case, and what is the *root* cause for the triple fault in the Ia32X64
>case?
>
>We can investigate some more:
>
>
>(4) The DXE IPL PEIM actually sets up the 0x38 segment correctly. In the
>HandOffToDxeCore() function
>[MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c], branch
>"

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

[Kinney, Michael D]

Paolo,

I do not know if it would help, but there is a hook point already defined in 
the SmmCpuFeaturesLib

/**
  Processor specific hook point each time a CPU enters System Management Mode.

  @param[in] CpuIndex  The index of the CPU that has entered SMM.  The value
   must be between 0 and the NumberOfCpus field in the
   System Management System Table (SMST).
**/
VOID
EFIAPI
SmmCpuFeaturesRendezvousEntry (
  IN UINTN  CpuIndex
  );

In the OVMF specific implementation of this lib, you can do special actions if 
CpuIndex is BSP, for example check to see if it is a SW SMI and send IPI to APs.

I also see that Jeff Fan has responded to the thread and is working on making 
sure the APs are in a good state between ExitBootServices() and OS wake of APs.

Best regards,

Mike

>-Original Message-
>From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
>Bonzini
>Sent: Sunday, October 25, 2015 7:53 PM
>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 

Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

[Kinney, Michael D]

Laszlo,

I do not believe any X64 PEI testing has not been performed with this module.  
We will investigate a fix.

Thanks,

Mike

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Wednesday, October 28, 2015 8:57 AM
>To: Fan, Jeff; Yao, Jiewen
>Cc: edk2-devel-01; Kinney, Michael D
>Subject: about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei
>
>Hi,
>
>I have a question about the following code in
>"UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c", function
>S3RestoreConfig2():
>
>> if (SmmS3ResumeState->Signature == SMM_S3_RESUME_SMM_64) {
>>   //
>>   // Switch to long mode to complete resume.
>>   //
>>
>>   InterruptStatus = SaveAndDisableInterrupts ();
>>   //
>>   // Need to make sure the GDT is loaded with values that support long
>mode and real mode.
>>   //
>>   AsmWriteGdtr ();
>>   //
>>   // update segment selectors per the new GDT.
>>   //
>>   AsmSetDataSelectors (DATA_SEGEMENT_SELECTOR);
>>   //
>>   // Restore interrupt state.
>>   //
>>   SetInterruptState (InterruptStatus);
>>
>>   AsmWriteCr3 ((UINTN)SmmS3ResumeState->SmmS3Cr3);
>>
>>   //
>>   // Disable interrupt of Debug timer, since IDT table cannot work in 
>> long
>mode.
>>   // NOTE: On x64 platforms, because DisablePaging64() will disable
>interrupts,
>>   // the code in S3ResumeExecuteBootScript() cannot be halted by soft
>debugger.
>>   //
>>   SaveAndSetDebugTimerInterrupt (FALSE);
>>
>>   AsmEnablePaging64 (
>> 0x38,
>> SmmS3ResumeState->SmmS3ResumeEntryPoint,
>> (UINT64)(UINTN)AcpiS3Context,
>> 0,
>> SmmS3ResumeState->SmmS3StackBase + SmmS3ResumeState-
>>SmmS3StackSize
>> );
>> }
>
>At the end of this block, the AsmEnablePaging64() function is called. That call
>results in the following call tree, *if* the module was built for X64:
>
>AsmEnablePaging64()   [MdePkg/Library/BaseLib/X86EnablePaging64.c]
>  InternalX86EnablePaging64() [MdePkg/Library/BaseLib/X64/Non-existing.c]
>ASSERT (FALSE)
>
>This is because the InternalX86EnablePaging64() functionality is unavailable in
>BaseLib on X64.
>
>My question: how is this branch in S3RestoreConfig2() supposed to work *at
>all* in an X64 PEI build?
>
>Thank you,
>Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdeModulePkg: Fix a PciBusDxe hot plug bug

[Kinney, Michael D]

Leif,

Please test the patch I just sent to see if it resolves your issue.

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif
>Lindholm
>Sent: Wednesday, October 28, 2015 7:51 AM
>To: Tian, Feng
>Cc: Ni, Ruiyu; edk2-devel@lists.01.org; Fan, Jeff
>Subject: Re: [edk2] [Patch] MdeModulePkg: Fix a PciBusDxe hot plug bug
>
>Feng,
>
>Any update on the below?
>The hard crash bug is still in SVN r18690.
>
>Regards,
>
>Leif
>
>On Mon, Oct 26, 2015 at 03:35:15PM +, Leif Lindholm wrote:
>> Hi Ray,
>>
>> On Mon, Oct 26, 2015 at 03:17:22PM +, Ni, Ruiyu wrote:
>> > Can you add a null pointer check to
>> > PciIoDevice->ResourcePaddingDescriptors before calling
>> > DumpPpbPaddingResource? Does it help?
>>
>> It removes the delay and the crash - thanks!
>>
>> But it does nothing for the commit history ;)
>>
>> Regards,
>>
>> Leif
>>
>> > > 在 2015年10月26日，21:13，Leif Lindholm 
>写道：
>> > >
>> > > Hi Ruiyu, Feng,
>> > >
>> > > I am currently tracking down an issue on (at least) one of my
>> > > platforms - that happens with this (now committed) patch, but not
>> > > without it.
>> > >
>> > > Symptoms are a _long_ delay, followed by an unaligned access in (I
>> > > think) DumpPpbPaddingResource.
>> > >
>> > > Anyway, there could be other things playing in here - I'm testing a
>> > > new card in a platform I haven't previously tested cards.
>> > >
>> > > But this is one large patch, which could have been split up into
>> > > multiple ones to make the introduced changes more reviewable:
>> > > - There are both functional changes and whitespace fixups.
>> > > - There are (text-only) changes to existing messages.
>> > > - There is refactoring of internal APIs.
>> > >
>> > > It is certainly too invasive a change to be committed ~32 minutes
>> > > after having first been posted to the list.
>> > >
>> > > Any chance we can revert this one and introduce it in smaller
>> > > portions, making the individual change sets more reviewable?
>> > >
>> > > Regards,
>> > >
>> > > Leif
>> > >
>> > >> On Fri, Oct 23, 2015 at 03:57:40PM +0800, Ruiyu Ni wrote:
>> > >> For a hot plug bridge with device attached, PciBusDxe driver reserves
>> > >> the resources which equal to the total amount of padding resource
>> > >> returned from HotPlug->GetResourcePadding() and the actual occupied
>> > >> resource by the attached device. The behavior is incorrect.
>> > >> Correct behavior is to reserve the bigger one between the padding
>> > >> resource and the actual occupied resource.
>> > >>
>> > >> Contributed-under: TianoCore Contribution Agreement 1.0
>> > >> Signed-off-by: Ruiyu Ni 
>> > >> Cc: Jeff Fan 
>> > >> Cc: Feng Tian 
>> > >> ---
>> > >> .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c   |  76 +-
>> > >> .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.h   |  13 ++
>> > >> MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c| 159 ++-
>--
>> > >> .../Bus/Pci/PciBusDxe/PciResourceSupport.c |  58 +---
>> > >> 4 files changed, 204 insertions(+), 102 deletions(-)
>> > >>
>> > >> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
>b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
>> > >> index f7aea4f..030ef42 100644
>> > >> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
>> > >> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
>> > >> @@ -325,6 +325,77 @@ PciSearchDevice (
>> > >> }
>> > >>
>> > >> /**
>> > >> +  Dump the PPB padding resource information.
>> > >> +
>> > >> +  @param PciIoDevice PCI IO instance.
>> > >> +  @param ResourceTypeThe desired resource type to dump.
>> > >> + PciBarTypeUnknown means to dump all types of
>resources.
>> > >> +**/
>> > >> +VOID
>> > >> +DumpPpbPaddingResource (
>> > >> +  IN PCI_IO_DEVICE*PciIoDevice,
>> > >> +  IN PCI_BAR_TYPE ResourceType
>> > >> +  )
>> > >> +{
>> > >> +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor;
>> > >> +  PCI_BAR_TYPE  Type;
>> > >> +
>> > >> +  if (ResourceType == PciBarTypeIo16 || ResourceType ==
>PciBarTypeIo32) {
>> > >> +ResourceType = PciBarTypeIo;
>> > >> +  }
>> > >> +
>> > >> +  for (Descriptor = PciIoDevice->ResourcePaddingDescriptors;
>Descriptor->Desc != ACPI_END_TAG_DESCRIPTOR; Descriptor++) {
>> > >> +
>> > >> +Type = PciBarTypeUnknown;
>> > >> +if (Descriptor->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR &&
>Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_IO) {
>> > >> +  Type = PciBarTypeIo;
>> > >> +} else if (Descriptor->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR
>&& Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) {
>> > >> +
>> > >> +  if (Descriptor->AddrSpaceGranularity == 32) {
>> > >> +//
>> > >> +// prefechable
>> > >> +//
>> > >> +if (Descriptor->SpecificFlag ==

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

[Kinney, Michael D]

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|0x0002

We could exit the wait loop as soon as the number of detected CPUs matches 
PcdCpuMaxLogicalProcessorNumber.

Mike


>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Wednesday, October 21, 2015 1:40 AM
>To: Justen, Jordan L
>Cc: Xiao Guangrong; Eduardo Habkost; edk2-de...@ml01.01.org; Alex
>Williamson; Kinney, Michael D
>Subject: Re: [edk2] [PATCH] OvmfPkg: increase MP services startup timeout
>
>CC'ing Eduardo
>
>On 10/20/15 23:39, Jordan Justen wrote:
>> On 2015-10-20 12:27:42, Laszlo Ersek wrote:
>>> Due to Linux kernel commit b18d5431acc7 ("KVM: x86: fix CR0.CD
>>> virtualization"), vCPUs need more time to start up, because:
>>>
>>> - KVM now zaps all the mappings for the guest memory in EPT or shadow
>page
>>>   table, hence more VM exits are required to rebuild the mappings for all
>>>   memory accesses.
>>>
>>> - If a physical device has been assigned to the guest, and the IOMMU lacks
>>>   the snoop control feature, guest memory will become uncacheable after
>>>   CR0.CD is set to 1.
>>>
>>> UefiCpuPkg/UefiCpuPkg.dec sets the timeout to 50ms; startup failures with
>>> 100ms have been reported. Xiao Guangrong suggested 1s, and helped
>word the
>>> commit message.
>>
>> We will wait 1 second each boot for APs to start up? Meaning we will
>> basically add 1 second to the OVMF boot time?
>
>Yes, in StartApsStackless() that's the case.
>
>> I wonder if we can get the actual max from QEMU and use it to tell
>> CpuDxe how many processors to wait for. This would allow it to bail
>> out earlier if all processors startup faster.
>
>QEMU exports two fw_cfg keys (not files -- directly keys) that are
>related to VCPU counts:
>
>  QemuFwCfgItemSmpCpuCount = 0x0005,
>
>  QemuFwCfgItemMaximumCpuCount = 0x000f,
>
>(called FW_CFG_NB_CPUS and FW_CFG_MAX_CPUS in the QEMU source,
>respectively).
>
>FW_CFG_MAX_CPUS is not really good for this, because it carries the
>maximum possible APIC ID value, plus one, not the maximum number of
>CPUs. Please see the big comment in bochs_bios_init() in QEMU
>[hw/i386/pc.c].
>
>FW_CFG_NB_CPUS exposes the "smp_cpus" variable of QEMU, which is the
>count of VCPUs present at QEMU startup (more can be hotplugged later).
>See the -smp option:
>
>  -smp [cpus=]n[,cores=cores][,threads=threads][,sockets=sockets]
>   [,maxcpus=maxcpus]
>
>"smp_cpus" corresponds to "n" in the above (where "cpus" is enforced to
>equal cores * threads * sockets ==> smp_parse()), whereas "maxcpus"
>means "maximum number of CPUs, including future hotplug" (variable
>"max_cpus", which is not exposed via fw_cfg at all).
>
>In addition, (smp_cpus - 1) is also visible in the CMOS, at offset 0x5f.
>
>Confused yet? Good; it is very confusing. Here's a summary:
>
>  quantity |QEMU command line |QEMU variable or  |guest
>interface
>   |  |function  |
>  
> -|--|--|---
>  initially|-smp cpus=|smp_cpus  
> |FW_CFG_NB_CPUS
>  plugged  |and/or|  |and
>  CPUs |-smp cores=,threads=,sockets= |  
> |cmos[0x5f] + 1
>  
> -+--+--+---
>  maximum  |-smp maxcpus= |max_cpus  |n/a
>  possible |  |  |
>  CPUs |  |  |
>  
> -+--+--+---
>  maximum  |-smp
>cores=,threads=,sockets=,maxcpus=|pc_apic_id_limit()|FW_CFG_MAX_CPUS
>  APIC ID  |(i.e., derived from topology and  |  |-1
>   |maximum possible count)   |  |
>
>SeaBIOS too counts the CPUs at startup (see smp_setup() in
>"src/fw/smp.c"). The quantity that it uses to terminate the loop is
>(cmos[0x5f] + 1) -- i.e., number of initially plugged CPUs.
>
>If we want to do something similar, then UefiCpuPkg/CpuDxe needs to
>accept and consider such a limit (from a dynamic PCD), and:
>
>

Re: [edk2] Authentication status for signed FVs extracted in PEI

[Kinney, Michael D]

Eugene,

I believe the current behavior is that only FVs that are either unsigned or FVs 
that are signed and pass authentication can be passed from PEI to DXE.

I believe your use case is to pass an FV from PEI to DXE that is signed, but 
has not been authenticated yet.

Given the current PI architecture constraints, would it be a reasonable 
solution to have an early DXE driver publish the FV that is signed but not 
authenticated yet, so the DXE phase can do the authentication?

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
>Eugene
>Sent: Tuesday, November 10, 2015 7:12 AM
>To: Gao, Liming; Zeng, Star; edk2-devel@lists.01.org
>Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
>
>Liming and Star,
>
>Thanks for the suggestion for extending the FV HOB.  I'm not sure if the 
>length change will be considered forwards and backwards
>compatible for all implementations.  If people refer to the HOB by pointer it 
>shouldn't be a problem but if they try to copy the HOB
>using the header length they may have a compatibility problem.
>
>I'll raise your suggestion at PIWG and see what the group recommends.
>
>Thanks,
>
>Eugene
>
>-Original Message-
>From: Gao, Liming [mailto:liming@intel.com]
>Sent: Tuesday, November 10, 2015 3:27 AM
>To: Zeng, Star ; Cohen, Eugene ; 
>edk2-devel@lists.01.org
>Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI
>
>Eugene:
>  Another idea is to update FV HOB to include authentication status instead of 
> adding FV HOB3. The consumer code can check FV HOB
>Length to know whether FV HOB includes authentication status.
>
>Thanks
>Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, 
>> Star
>> Sent: Tuesday, November 10, 2015 6:19 PM
>> To: Cohen, Eugene; edk2-devel@lists.01.org
>> Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
>>
>> On 2015/11/9 21:57, Cohen, Eugene wrote:
>> > Star,
>> >
>> >> The authentication status and its inheritance support in FvInfo2 and 
>> >> FvPpi were covered by the mantis we submitted to support
>PEI
>> security and to be equivalent with DXE.
>> > You raised another issue here to inherit authentication status from PEI to 
>> > DXE.
>> >
>> > Correct.
>> >
>> >> Currently, only verified pass FV in PEI will be processed and reported 
>> >> with FV HOB to DXE.
>> >
>> > The FV HOB doesn't explicitly say whether the FV was verified or not.  We 
>> > have a use case where we have one FV that contains
>code
>> and is verified and another FV that contains some data and is not verified.  
>> With the current FV HOB definitions there's no way to
>> differentiate these two.
>>
>> Curious about the FV you said is root or child FV?
>>
>> >
>> > The DXE core just assumes that all FVs passed through FV hobs are unsigned 
>> > (AuthenticationStatus = 0).  So in DXE-phase security
>> policy callbacks (part of EFI_SECURITY_ARCH_PROTOCOL) we are not getting 
>> accurate AuthenticationStatus values with which to
>make a
>> decision.
>> >
>> > So in a way this just seems wrong since the security callbacks are saying 
>> > that FVs are unsigned when in reality there are signed and
>> verified.
>> >
>> > I'm thinking this could be as simple as an updated FV HOB definition that 
>> > adds an AuthenticationStatus field.
>>
>> I agree it is a gap. I have seen the mantis you filed to add FV3 HOB to
>> include AuthenticationStatus. Then there will be FV/FV2/FV3 HOB for one
>> FV. Seemingly, we could not to just extend FV HOB to include
>> AuthenticationStatus, right?
>>
>> Thanks,
>> Star
>>
>> >
>> > Eugene
>> >
>> > -Original Message-
>> > From: Zeng, Star [mailto:star.z...@intel.com]
>> > Sent: Monday, November 09, 2015 6:43 AM
>> > To: Cohen, Eugene ; edk2-devel@lists.01.org
>> > Cc: Zeng, Star 
>> > Subject: RE: Authentication status for signed FVs extracted in PEI
>> >
>> > The authentication status and its inheritance support in FvInfo2 and FvPpi 
>> > were covered by the mantis we submitted to support
>PEI
>> security and to be equivalent with DXE.
>> > You raised another issue here to inherit authentication status from PEI to 
>> > DXE.
>> >
>> > Currently, only verified pass FV in PEI will be processed and reported 
>> > with FV HOB to DXE.
>> > Your real case will have different policy to verify FV in PEI and DXE 
>> > phase?
>> >
>> > Thanks,
>> > Star
>> > -Original Message-
>> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> > Cohen, Eugene
>> > Sent: Monday, November 9, 2015 9:03 PM
>> > To: edk2-devel@lists.01.org
>> > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
>> >
>> > I raised this as an issue with PIWG.  In the meantime feel free to provide 
>> > some historical context for why this hasn't been 

Re: [edk2] [RFC] Adaptively set serial terminal input polling interval

[Kinney, Michael D]

Heyi,

All timers in UEFI are the minimum time.  So the only way to guarantee that a 
FIFO will never overflow is to use flow control.

Setting the poll rate based on FIFO depth and baud rate, data bits, and stop 
bits with flow control disabled means it should work most of the time, but 
another UEFI event notification function running at the same TPL or higher can 
block the Terminal event notification function and input characters could be 
lost.

I agree that the current 20ms periodic timer can overflow depending in the FIFO 
depth and the baud rate, and that we could reduce data loss in flow control 
disabled configurations if this periodic rate was computed instead of using a 
hard coded #define.  Another constraint is the system timer interrupt rate 
provided by the Timer Architectural Protocol.  A request for a periodic timer 
event that is faster than the current system timer rate will call the event 
notification function at the rate of the system timer.  So even if you reduce 
the periodic timer event time to a computed value, the time between event 
notification function calls may not change.  

In order to prevent overflows, I think the timer rate in 100ns units could be 
computed as follows:

Receive FIFO depth * (1 + DataBits + StopBits) * 10,000,000

--
BaudRate  

For example, a 16 byte receive FIFO with 8 data bits and 1 stop bit at 115200 
would be:

16 * (1 + 8 + 1) * 10,000,000 / 115200 = 15277

Which is 0.00153 seconds or 1.53 ms.

Best regards,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
>Sent: Monday, November 09, 2015 10:23 PM
>To: Kinney, Michael D; edk2-devel@lists.01.org
>Cc: Tian, Feng
>Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling interval
>
>Hi Michael,
>
>Yes we can see terminal input truncated when we use copy-paste to input
>characters.
>
>I don't quite understand the relationship between SerialInTimeOut and
>timer event poll rate; and I don't see the periodic timer rate is to be
>updated later; we are using 0.02ms period all over, aren't we?
>
>If the timer event polls the serial device at a fixed rate, how can we
>guarantee the FIFO of the device will not overflow during a burst input?
>
>Thanks.
>
>On 11/10/2015 01:25 AM, Kinney, Michael D wrote:
>> Heyi,
>>
>> The function TerminalConInTimerHandler () computes a timeout based on the 
>> baud rate, data bits, and stop bits
>>
>>//
>>// According to BAUD rate to calculate the timeout value.
>>//
>>SerialInTimeOut = (1 + Mode->DataBits + Mode->StopBits) * 2 * 100 
>> / (UINTN) Mode->BaudRate;
>>
>> The #define is used to set the initial periodic timer rate before the rest 
>> of the information to compute a timeout is known.
>>
>> Are you observing an issue?
>>
>> Mike
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi
>>> Guo
>>> Sent: Monday, November 09, 2015 1:48 AM
>>> To: edk2-devel@lists.01.org
>>> Cc: Tian, Feng
>>> Subject: [edk2] [RFC] Adaptively set serial terminal input polling interval
>>>
>>> Hi All,
>>>
>>> In MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf, the
>>> polling interval is fixed by macro:
>>>
>>> #define KEYBOARD_TIMER_INTERVAL 20  // 0.02s
>>>
>>> However, this may cause fast input to be truncated on some platform. For
>>> example, we have a serial console with below features:
>>> 1. Baud rate: 115200
>>> 2. FIFO depth of UART device: 32
>>>
>>> If we want to capture all input, we need to poll with the interval of 32
>>> / (115200 / (8 + 1 + 1)) = 2.8 ms, 8 + 1 + 1 for data bits + start bit +
>>> stop bit.
>>>
>>> So, I suppose to use a PCD to set the interval per platform, or
>>> calculate from serial IO protocol IO Mode, which contains FIFO depth and
>>> data bits, etc, and we can use 20 as the maximum for compatibility,
>>> or default value when fifo depth is 0.
>>>
>>> Please let me know your comments.
>>>
>>> Thanks.
>>>
>>> Heyi
>>> ___
>>> 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Adaptively set serial terminal input polling interval

[Kinney, Michael D]

Heyi,

The function TerminalConInTimerHandler () computes a timeout based on the baud 
rate, data bits, and stop bits

  //
  // According to BAUD rate to calculate the timeout value.
  //
  SerialInTimeOut = (1 + Mode->DataBits + Mode->StopBits) * 2 * 100 / 
(UINTN) Mode->BaudRate;

The #define is used to set the initial periodic timer rate before the rest of 
the information to compute a timeout is known.

Are you observing an issue?

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi
>Guo
>Sent: Monday, November 09, 2015 1:48 AM
>To: edk2-devel@lists.01.org
>Cc: Tian, Feng
>Subject: [edk2] [RFC] Adaptively set serial terminal input polling interval
>
>Hi All,
>
>In MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf, the
>polling interval is fixed by macro:
>
>#define KEYBOARD_TIMER_INTERVAL 20  // 0.02s
>
>However, this may cause fast input to be truncated on some platform. For
>example, we have a serial console with below features:
>1. Baud rate: 115200
>2. FIFO depth of UART device: 32
>
>If we want to capture all input, we need to poll with the interval of 32
>/ (115200 / (8 + 1 + 1)) = 2.8 ms, 8 + 1 + 1 for data bits + start bit +
>stop bit.
>
>So, I suppose to use a PCD to set the interval per platform, or
>calculate from serial IO protocol IO Mode, which contains FIFO depth and
>data bits, etc, and we can use 20 as the maximum for compatibility,
>or default value when fifo depth is 0.
>
>Please let me know your comments.
>
>Thanks.
>
>Heyi
>___
>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] [RFC] Adaptively set serial terminal input polling interval

[Kinney, Michael D]

Heyi,

Yes.  I think computing the poll rate is a good addition to the TerminalDxe 
module.

If any of the information required to compute the rate is not available, then 
the #define default rate can be used.

Do you want to prepare a patch with this enhancement?

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
>Sent: Tuesday, November 10, 2015 5:27 PM
>To: Kinney, Michael D; edk2-devel@lists.01.org
>Cc: Tian, Feng
>Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling interval
>
>
>
>On 11/11/2015 04:34 AM, Kinney, Michael D wrote:
>> Heyi,
>>
>> All timers in UEFI are the minimum time.  So the only way to guarantee that 
>> a FIFO will never overflow is to use flow control.
>>
>> Setting the poll rate based on FIFO depth and baud rate, data bits, and stop 
>> bits with flow control disabled means it should work
>most of the time, but another UEFI event notification function running at the 
>same TPL or higher can block the Terminal event
>notification function and input characters could be lost.
>>
>> I agree that the current 20ms periodic timer can overflow depending in the 
>> FIFO depth and the baud rate, and that we could reduce
>data loss in flow control disabled configurations if this periodic rate was 
>computed instead of using a hard coded #define.  Another
>constraint is the system timer interrupt rate provided by the Timer 
>Architectural Protocol.  A request for a periodic timer event that is
>faster than the current system timer rate will call the event notification 
>function at the rate of the system timer.  So even if you
>reduce the periodic timer event time to a computed value, the time between 
>event notification function calls may not change.
>Totally agree. However normally we will have platform configuration
>interface for interrupt rate of system timer, like PCD or even driver
>override, but I can't find any interface to configure polling rate of
>the terminal driver, and I really don't like to override the whole
>terminal driver when I only want to change the polling rate :). That's
>the reason why I want to make a patch for terminal driver.
>
>>
>> In order to prevent overflows, I think the timer rate in 100ns units could 
>> be computed as follows:
>>
>>  Receive FIFO depth * (1 + DataBits + StopBits) * 10,000,000
>>  
>> --
>>  BaudRate
>>
>> For example, a 16 byte receive FIFO with 8 data bits and 1 stop bit at 
>> 115200 would be:
>>
>>  16 * (1 + 8 + 1) * 10,000,000 / 115200 = 15277
>>
>> Which is 0.00153 seconds or 1.53 ms.
>Can I consider this as your agreement on calculating polling rate in
>terminal driver?
>
>After all, really appreciate your detailed answer on this issue.
>
>Heyi
>
>>
>> Best regards,
>>
>> Mike
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
>>> Guo
>>> Sent: Monday, November 09, 2015 10:23 PM
>>> To: Kinney, Michael D; edk2-devel@lists.01.org
>>> Cc: Tian, Feng
>>> Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling 
>>> interval
>>>
>>> Hi Michael,
>>>
>>> Yes we can see terminal input truncated when we use copy-paste to input
>>> characters.
>>>
>>> I don't quite understand the relationship between SerialInTimeOut and
>>> timer event poll rate; and I don't see the periodic timer rate is to be
>>> updated later; we are using 0.02ms period all over, aren't we?
>>>
>>> If the timer event polls the serial device at a fixed rate, how can we
>>> guarantee the FIFO of the device will not overflow during a burst input?
>>>
>>> Thanks.
>>>
>>> On 11/10/2015 01:25 AM, Kinney, Michael D wrote:
>>>> Heyi,
>>>>
>>>> The function TerminalConInTimerHandler () computes a timeout based on the 
>>>> baud rate, data bits, and stop bits
>>>>
>>>> //
>>>> // According to BAUD rate to calculate the timeout value.
>>>> //
>>>> SerialInTimeOut = (1 + Mode->DataBits + Mode->StopBits) * 2 * 
>>>> 100 / (UINTN) Mode->BaudRate;
>>>>
>>>> The #define is used to set the initial periodic timer rate before the rest 
>>>> of the information to compute a timeout is known.
>>>>
>&

Re: [edk2] [RFC] Adaptively set serial terminal input polling interval

[Kinney, Michael D]

Heyi,

I think it should be ok to always calculate it.  

I think the only time the #define default rate should be used is if the 
BaudRate is 0.

Similar to setting the SerialInTimeOut, you can check in the periodic timer 
event notification function to see if the Baud Rate, Data Bits, Stop Bits, or 
Receive FIFO depth have changed, and if they have, compute and set the new 
periodic timer rate for the event.

Mike

>-Original Message-
>From: Heyi Guo [mailto:heyi@linaro.org]
>Sent: Tuesday, November 10, 2015 7:07 PM
>To: Kinney, Michael D; edk2-devel@lists.01.org
>Cc: Tian, Feng
>Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling interval
>
>
>
>On 11/11/2015 10:06 AM, Kinney, Michael D wrote:
>> Heyi,
>>
>> Yes.  I think computing the poll rate is a good addition to the TerminalDxe 
>> module.
>>
>> If any of the information required to compute the rate is not available, 
>> then the #define default rate can be used.
>>
>> Do you want to prepare a patch with this enhancement?
>Sure, it's my pleasure.
>
>Do you think it is necessary to still use the default rate if the
>calculated result is *larger* than it, to make it back compatible? It is
>possible some old code has wrong FIFO depth stated.
>
>Thanks.
>>
>> Thanks,
>>
>> Mike
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
>>> Guo
>>> Sent: Tuesday, November 10, 2015 5:27 PM
>>> To: Kinney, Michael D; edk2-devel@lists.01.org
>>> Cc: Tian, Feng
>>> Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling 
>>> interval
>>>
>>>
>>>
>>> On 11/11/2015 04:34 AM, Kinney, Michael D wrote:
>>>> Heyi,
>>>>
>>>> All timers in UEFI are the minimum time.  So the only way to guarantee 
>>>> that a FIFO will never overflow is to use flow control.
>>>>
>>>> Setting the poll rate based on FIFO depth and baud rate, data bits, and 
>>>> stop bits with flow control disabled means it should work
>>> most of the time, but another UEFI event notification function running at 
>>> the same TPL or higher can block the Terminal event
>>> notification function and input characters could be lost.
>>>> I agree that the current 20ms periodic timer can overflow depending in the 
>>>> FIFO depth and the baud rate, and that we could
>reduce
>>> data loss in flow control disabled configurations if this periodic rate was 
>>> computed instead of using a hard coded #define.
>Another
>>> constraint is the system timer interrupt rate provided by the Timer 
>>> Architectural Protocol.  A request for a periodic timer event
>that is
>>> faster than the current system timer rate will call the event notification 
>>> function at the rate of the system timer.  So even if you
>>> reduce the periodic timer event time to a computed value, the time between 
>>> event notification function calls may not change.
>>> Totally agree. However normally we will have platform configuration
>>> interface for interrupt rate of system timer, like PCD or even driver
>>> override, but I can't find any interface to configure polling rate of
>>> the terminal driver, and I really don't like to override the whole
>>> terminal driver when I only want to change the polling rate :). That's
>>> the reason why I want to make a patch for terminal driver.
>>>
>>>> In order to prevent overflows, I think the timer rate in 100ns units could 
>>>> be computed as follows:
>>>>
>>>>Receive FIFO depth * (1 + DataBits + StopBits) * 10,000,000
>>>>
>>>> --
>>>>BaudRate
>>>>
>>>> For example, a 16 byte receive FIFO with 8 data bits and 1 stop bit at 
>>>> 115200 would be:
>>>>
>>>>16 * (1 + 8 + 1) * 10,000,000 / 115200 = 15277
>>>>
>>>> Which is 0.00153 seconds or 1.53 ms.
>>> Can I consider this as your agreement on calculating polling rate in
>>> terminal driver?
>>>
>>> After all, really appreciate your detailed answer on this issue.
>>>
>>> Heyi
>>>
>>>> Best regards,
>>>>
>>>> Mike
>>>>
>>>>> -Original Message-
>>>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On

Re: [edk2] [PATCH v4 18/41] OvmfPkg: select LocalApicLib instance with x2apic support if SMM_REQUIRE

[Kinney, Michael D]

Laszlo,

Yes.  They are compatible.  And I do recommend switching to BaseXApicX2ApicLib 
unconditionally.
 
Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Wednesday, November 04, 2015 12:09 PM
>To: Kinney, Michael D; Paolo Bonzini; edk2-de...@ml01.01.org; Fan, Jeff;
>Justen, Jordan L
>Subject: Re: [edk2] [PATCH v4 18/41] OvmfPkg: select LocalApicLib instance
>with x2apic support if SMM_REQUIRE
>
>On 11/04/15 17:55, Kinney, Michael D wrote:
>> Laszlo,
>>
>> BaseXApicX2ApicLib is intended to be used by platforms that support more
>>=256 CPUs.
>>
>> If the current system configuration is < 256 CPUs, then the platform will
>typically stay in APIC mode.  If >= 256 CPUs are detected, then X2 APIC mode
>can be enabled using the following API.
>>
>> VOID
>> EFIAPI
>> SetApicMode (
>>   IN UINTN  ApicMode
>>   )
>>
>> So just adding BaseXApicX2ApicLib to the DSC does not enable X2 APIC
>mode.  You have to add logic to enable X2 APIC mode.
>>
>> I see that QEMU is limited to 255 VCPUs, so the use of BaseXApicLib makes
>sense.  Are OVMF configurations supported with >= 256 VCPUs?
>
>I don't think so, but 64-bit Linux guest kernels enable x2apic mode
>anyway, apparently regardless of the VCPU count and topology.
>
>This is normally not a problem, but with SMM support, the APIC library
>gets used (within SMM) *after* Linux configures x2apic mode. This causes
>the "basic" library instance to blow up. Therefore I flipped the library
>class resolution to the one instance that supports x2apic mode, but only
>for the SMM build of OVMF.
>
>So, the question Paolo and I have is *not* whether we must use the
>x2apic-capable library in the SMM build -- that is a fact, forced by the
>X64 Linux guest kernel's behavior.
>
>Neither is our question "how could we enable x2apic mode"? About that,
>we don't care at the moment. :)
>
>Instead, our question is if we can use BaseXApicX2ApicLib even in the
>*non*-SMM build, without fear of regressions. In other words, if
>BaseXApicX2ApicLib can safely replace BaseXApicLib in a build where
>BaseXApicLib would be otherwise fully sufficient.
>
>Because, if the answer is "yes, it is compatible", then we shouldn't
>complicate the library class resolution in the OVMF DSC files, making it
>dependent on the build type (i.e., SMM -> BaseXApicX2ApicLib, non-SMM ->
>BaseXApicLib). Rather than that, we should indiscriminately use
>BaseXApicX2ApicLib.
>
>So... is BaseXApicX2ApicLib compatible with BaseXApicLib in the domain
>where the latter would work sufficiently?
>
>Thanks!
>Laszlo
>
>
>>
>> Thanks,
>>
>> Mike
>>
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Wednesday, November 04, 2015 2:41 AM
>>> To: Paolo Bonzini; edk2-de...@ml01.01.org; Kinney, Michael D; Fan, Jeff;
>>> Justen, Jordan L
>>> Subject: Re: [edk2] [PATCH v4 18/41] OvmfPkg: select LocalApicLib instance
>>> with x2apic support if SMM_REQUIRE
>>>
>>> On 11/04/15 09:48, Paolo Bonzini wrote:
>>>>
>>>>
>>>> On 03/11/2015 22:00, Laszlo Ersek wrote:
>>>>> +
>>>>> +!if $(SMM_REQUIRE) == TRUE
>>>>> +
>>>
>LocalApicLib|UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
>>>>> +!else
>>>>>LocalApicLib|UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
>>>>> +!endif
>>>>> +
>>>>
>>>> Can we enable BaseXApicX2ApicLib unconditionally?
>>>
>>> I think I am technically capable of that :), but should we? We haven't
>>> used BaseXApicX2ApicLib thus far in OVMF, so I can't predict at all if
>>> it could regress stuff or not. If it causes problems with the
>>> SMM_REQUIRE build, so be it, that's new stuff, but I wanted to avoid
>>> such a global change for the traditional build.
>>>
>>> I'm not against it, I just don't have experience with BaseXApicX2ApicLib.
>>>
>>> Mike, Jeff, Jordan -- what do you think? Why do separate BaseXApicLib
>>> and BaseXApicX2ApicLib instances exist? And why has OvmfPkg always
>used
>>> the former? If it has only been for simplicity's sake, and
>>> BaseXApicX2ApicLib is otherwise widely used internally at Intel, then I
>>> think Paolo is right, and we should just keep the OVMF DSCs simple.
>>>
>>> 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 v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

[Kinney, Michael D]

Laszlo,

For the EFI_PEI_COMMUNICATION_PPI, is there a reason you are not using 
UefiCpuPkg\PiSmmCommunication\PiSmmCommunicationPei.inf to produce that PPI?

Thanks,

Mike

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Tuesday, November 03, 2015 1:01 PM
>To: edk2-de...@ml01.01.org
>Cc: Kinney, Michael D; Justen, Jordan L
>Subject: [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM
>during PEI
>
>"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the library
>instance that implements the LockBoxLib library class with SMRAM access
>for the PEI phase.
>
>Introduce a PEIM that produces the EFI_PEI_SMM_COMMUNICATION_PPI and
>PEI_SMM_ACCESS_PPI interfaces, enabling SmmLockBoxPeiLib to work.
>
>Said library instance can parse and access LockBox data itself (without
>additional LockBox drivers) if the
>EFI_PEI_SMM_COMMUNICATION_PPI.Communicate() function returns
>EFI_NOT_STARTED to it. However it requires that
>EFI_PEI_SMM_COMMUNICATION_PPI exist at least. Also,
>PEI_SMM_ACCESS_PPI
>must exist and work.
>
>The load / installation order of S3Resume2Pei and SmmAccessPei is
>indifferent. SmmAccessPei produces the GUIDed HOB during its installation
>(which happens during PEI), but S3Resume2Pei accesses the HOB only when
>the DXE IPL calls its S3RestoreConfig2 PPI member, as last act of PEI.
>
>MCH_SMRAM_D_LCK and MCH_ESMRAMC_T_EN are masked out the way
>they are, in
>SmmAccessPeiEntryPoint() and SmramAccessOpen() respectively, in order to
>prevent VS20xx from warning about the (otherwise fully intentional)
>truncation in the UINT8 casts. (Warnings reported by Michael Kinney.)
>
>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: Laszlo Ersek <ler...@redhat.com>
>---
>
>Notes:
>v3:
>- update bit-neg expressions to silence VS20xx warnings [Mike]
>
> OvmfPkg/OvmfPkgIa32.dsc|   6 +
> OvmfPkg/OvmfPkgIa32X64.dsc |   6 +
> OvmfPkg/OvmfPkgX64.dsc |   6 +
> OvmfPkg/OvmfPkgIa32.fdf|   3 +
> OvmfPkg/OvmfPkgIa32X64.fdf |   3 +
> OvmfPkg/OvmfPkgX64.fdf |   3 +
> OvmfPkg/SmmAccess/SmmAccessPei.inf |  70 +++
> OvmfPkg/SmmAccess/SmramInternal.h  |  89 
> OvmfPkg/SmmAccess/SmmAccessPei.c   | 446 
> OvmfPkg/SmmAccess/SmramInternal.c  | 188 +
> 10 files changed, 820 insertions(+)
>
>diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>index c6850ff..0b729ca 100644
>--- a/OvmfPkg/OvmfPkgIa32.dsc
>+++ b/OvmfPkg/OvmfPkgIa32.dsc
>@@ -445,6 +445,12 @@ [Components]
> 
>   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>   }
>+!if $(SMM_REQUIRE) == TRUE
>+  OvmfPkg/SmmAccess/SmmAccessPei.inf {
>+
>+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>+  }
>+!endif
>
>   #
>   # DXE Phase modules
>diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>index dd65bf9..7f672d9 100644
>--- a/OvmfPkg/OvmfPkgIa32X64.dsc
>+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>@@ -451,6 +451,12 @@ [Components.IA32]
> 
>   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>   }
>+!if $(SMM_REQUIRE) == TRUE
>+  OvmfPkg/SmmAccess/SmmAccessPei.inf {
>+
>+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>+  }
>+!endif
>
> [Components.X64]
>   #
>diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>index 0de3c85..986c019 100644
>--- a/OvmfPkg/OvmfPkgX64.dsc
>+++ b/OvmfPkg/OvmfPkgX64.dsc
>@@ -450,6 +450,12 @@ [Components]
> 
>   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>   }
>+!if $(SMM_REQUIRE) == TRUE
>+  OvmfPkg/SmmAccess/SmmAccessPei.inf {
>+
>+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>+  }
>+!endif
>
>   #
>   # DXE Phase modules
>diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
>index 44e4a92..650dab1 100644
>--- a/OvmfPkg/OvmfPkgIa32.fdf
>+++ b/OvmfPkg/OvmfPkgIa32.fdf
>@@ -171,6 +171,9 @@ [FV.PEIFV]
> INF  OvmfPkg/PlatformPei/PlatformPei.inf
> INF  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> INF  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
>+!if $(SMM_REQUIRE) == TRUE
>+INF  OvmfPkg/SmmAccess/SmmAccessPei.inf
>+!endif
>
>
>#
>###
>
>diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
>index 67bfbe7..5830401 100644
>--- a/OvmfPkg/OvmfPkgIa32X64.fdf
>+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
>@@ -171,6 +171,9 @@ [FV.PEIFV]
> INF  OvmfPkg/PlatformPei/PlatformPei.inf
> INF  MdeModulePkg/Core/DxeIplP

Re: [edk2] [Patch] BaseTools: Print PACKAGES_PATH build environment if it is set.

[Kinney, Michael D]

Liming,

Why do you a different method than WORKSPACE to display the PACKAGES_PATH and 
EDK_TOOLS_BIN environment variables?

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Liming Gao
>Sent: Tuesday, November 03, 2015 5:15 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] BaseTools: Print PACKAGES_PATH build environment if
>it is set.
>
>Print the optional build environment PACKAGES_PATH and EDK_TOOLS_BIN.
>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Liming Gao 
>---
> BaseTools/Source/Python/build/build.py | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/BaseTools/Source/Python/build/build.py
>b/BaseTools/Source/Python/build/build.py
>index 30ff5bb..67bd3b3 100644
>--- a/BaseTools/Source/Python/build/build.py
>+++ b/BaseTools/Source/Python/build/build.py
>@@ -780,10 +780,14 @@ class Build():
>
> # print current build environment and configuration
> EdkLogger.quiet("%-16s = %s" % ("WORKSPACE",
>os.environ["WORKSPACE"]))
>+if "PACKAGES_PATH" in os.environ:
>+EdkLogger.quiet("%-16s = %s" % ("PACKAGES_PATH",
>os.path.normcase(os.path.normpath(os.environ["PACKAGES_PATH"]
> EdkLogger.quiet("%-16s = %s" % ("ECP_SOURCE",
>os.environ["ECP_SOURCE"]))
> EdkLogger.quiet("%-16s = %s" % ("EDK_SOURCE",
>os.environ["EDK_SOURCE"]))
> EdkLogger.quiet("%-16s = %s" % ("EFI_SOURCE",
>os.environ["EFI_SOURCE"]))
> EdkLogger.quiet("%-16s = %s" % ("EDK_TOOLS_PATH",
>os.environ["EDK_TOOLS_PATH"]))
>+if "EDK_TOOLS_BIN" in os.environ:
>+EdkLogger.quiet("%-16s = %s" % ("EDK_TOOLS_BIN",
>os.path.normcase(os.path.normpath(os.environ["EDK_TOOLS_BIN"]
>
> EdkLogger.info("")
>
>--
>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] BaseTools: Don't require ECP pkg in WORKSPACE when PACKAGES_PATH is set

[Kinney, Michael D]

Reviewed-by: Michael Kinney 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Liming Gao
>Sent: Tuesday, November 03, 2015 3:52 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] BaseTools: Don't require ECP pkg in WORKSPACE when
>PACKAGES_PATH is set
>
>When PACKAGES_PATH is set, ECP pkg may be in another directory, not exist
>in WORKSPACE. So, keep this check in single WORKSPACE.
>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Liming Gao 
>---
> BaseTools/Source/Python/build/build.py | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
>diff --git a/BaseTools/Source/Python/build/build.py
>b/BaseTools/Source/Python/build/build.py
>index b5df773..30ff5bb 100644
>--- a/BaseTools/Source/Python/build/build.py
>+++ b/BaseTools/Source/Python/build/build.py
>@@ -156,16 +156,18 @@ def CheckEnvVariable():
> EdkLogger.error("build", FORMAT_NOT_SUPPORTED, "No space is
>allowed in EFI_SOURCE path",
> ExtraData=EfiSourceDir)
>
>-# change absolute path to relative path to WORKSPACE
>-if EfiSourceDir.upper().find(WorkspaceDir.upper()) != 0:
>-EdkLogger.error("build", PARAMETER_INVALID, "EFI_SOURCE is not
>under WORKSPACE",
>-ExtraData="WORKSPACE = %s\nEFI_SOURCE = %s" %
>(WorkspaceDir, EfiSourceDir))
>-if EdkSourceDir.upper().find(WorkspaceDir.upper()) != 0:
>-EdkLogger.error("build", PARAMETER_INVALID, "EDK_SOURCE is not
>under WORKSPACE",
>-ExtraData="WORKSPACE = %s\nEDK_SOURCE = %s" %
>(WorkspaceDir, EdkSourceDir))
>-if EcpSourceDir.upper().find(WorkspaceDir.upper()) != 0:
>-EdkLogger.error("build", PARAMETER_INVALID, "ECP_SOURCE is not
>under WORKSPACE",
>-ExtraData="WORKSPACE = %s\nECP_SOURCE = %s" %
>(WorkspaceDir, EcpSourceDir))
>+# check those variables on single workspace case
>+if not PackagesPath:
>+# change absolute path to relative path to WORKSPACE
>+if EfiSourceDir.upper().find(WorkspaceDir.upper()) != 0:
>+EdkLogger.error("build", PARAMETER_INVALID, "EFI_SOURCE is not
>under WORKSPACE",
>+ExtraData="WORKSPACE = %s\nEFI_SOURCE = %s" %
>(WorkspaceDir, EfiSourceDir))
>+if EdkSourceDir.upper().find(WorkspaceDir.upper()) != 0:
>+EdkLogger.error("build", PARAMETER_INVALID, "EDK_SOURCE is not
>under WORKSPACE",
>+ExtraData="WORKSPACE = %s\nEDK_SOURCE = %s" %
>(WorkspaceDir, EdkSourceDir))
>+if EcpSourceDir.upper().find(WorkspaceDir.upper()) != 0:
>+EdkLogger.error("build", PARAMETER_INVALID, "ECP_SOURCE is not
>under WORKSPACE",
>+ExtraData="WORKSPACE = %s\nECP_SOURCE = %s" %
>(WorkspaceDir, EcpSourceDir))
>
> # check EDK_TOOLS_PATH
> if "EDK_TOOLS_PATH" not in os.environ:
>--
>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 v4 06/41] OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire set

[Kinney, Michael D]

Laszlo,

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

Mike

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Tuesday, November 03, 2015 1:01 PM
>To: edk2-de...@ml01.01.org
>Cc: Kinney, Michael D
>Subject: [PATCH v4 06/41] OvmfPkg: PlatformPei: account for TSEG size with
>PcdSmmSmramRequire set
>
>PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations:
>
>- PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed
>  so that it ends with the RAM below 4GB,
>
>- QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are
>  created for the RAM below 4GB; plus MTRR attributes are set
>  (independently of S3 vs. normal boot)
>
>- MemMapInitialization(): an MMIO resource descriptor HOB is created for
>  PCI resource allocation, on normal boot, starting at max(RAM below 4GB,
>  2GB).
>
>The first two of these is adjusted for the configured TSEG size, if
>PcdSmmSmramRequire is set:
>
>- In PublishPeiMemory(), the permanent PEI RAM is kept under TSEG.
>
>- In QemuInitializeRam(), we must keep the DXE out of TSEG.
>
>  One idea would be to simply trim the [1MB .. LowerMemorySize] memory
>  resource descriptor HOB, leaving a hole for TSEG in the memory space
>  map.
>
>  The SMM IPL will however want to massage the caching attributes of the
>  SMRAM range that it loads the SMM core into, with
>  gDS->SetMemorySpaceAttributes(), and that won't work on a hole. So,
>  instead of trimming this range, split the TSEG area off, and report it
>  as a cacheable reserved memory resource.
>
>  Finally, since reserved memory can be allocated too, pre-allocate TSEG
>  in InitializeRamRegions(), after QemuInitializeRam() returns. (Note that
>  this step alone does not suffice without the resource descriptor HOB
>  trickery: if we omit that, then the DXE IPL PEIM fails to load and start
>  the DXE core.)
>
>- In MemMapInitialization(), the start of the PCI MMIO range is not
>  affected.
>
>We choose the largest option (8MB) for the default TSEG size. Michael
>Kinney pointed out that the SMBASE relocation in PiSmmCpuDxeSmm
>consumes
>SMRAM proportionally to the number of CPUs. From the three options
>available, he reported that 8MB was both necessary and sufficient for the
>SMBASE relocation to succeed with 255 CPUs:
>
>- http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3137
>- http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3177
>
>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: Jordan Justen <jordan.l.jus...@intel.com>
>---
>
>Notes:
>v4:
>- drop the patch "OvmfPkg: double the SMRAM (TSEG) size for the 64-bit
>  DXE phase builds", and change the default TSEG size from 1MB to 8MB
>  globally [Mike]
>
> OvmfPkg/OvmfPkg.dec |  7 
> OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
> OvmfPkg/PlatformPei/MemDetect.c | 34 +++-
> 3 files changed, 41 insertions(+), 1 deletion(-)
>
>diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
>index 3fab2af..04859b4 100644
>--- a/OvmfPkg/OvmfPkg.dec
>+++ b/OvmfPkg/OvmfPkg.dec
>@@ -93,6 +93,13 @@ [PcdsFixedAtBuild]
>   gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxTargetLimit|31|UINT16|6
>   gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxLunLimit|7|UINT32|7
>
>+  ## The following setting controls how many megabytes we configure as
>TSEG on
>+  #  Q35, for SMRAM purposes. Permitted values are: 1, 2, 8. Other values
>cause
>+  #  undefined behavior.
>+  #
>+  #  This PCD is only consulted if PcdSmmSmramRequire is TRUE (see below).
>+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8|UINT8|0x20
>+
> [PcdsFixedAtBuild]
>
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase|0x0|UIN
>T32|0x8
>
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize|0x0|UINT
>32|0x9
>diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf
>b/OvmfPkg/PlatformPei/PlatformPei.inf
>index 62f64fe..ee044a2 100644
>--- a/OvmfPkg/PlatformPei/PlatformPei.inf
>+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
>@@ -75,6 +75,7 @@ [Pcd]
>   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
>   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
>   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
>+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
>
>gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySiz
>e
>   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
>   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
>diff --git a/OvmfPkg/P

Re: [edk2] C Coding Standards Specification disappeared

[Kinney, Michael D]

Laszlo,

I agree cast operators need their own rule in the coding standard.

I prefer to use () with sizeof().  For example, some compilers do not seem to 
like sizeof CHAR16, but they work with sizeof (CHAR16).  

Mike


>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Thursday, November 05, 2015 9:31 AM
>To: Daryl McDaniel
>Cc: 'edk2-devel@lists.01.org'
>Subject: Re: [edk2] C Coding Standards Specification disappeared
>
>On 11/05/15 18:03, Daryl McDaniel wrote:
>> Laszlo,
>>
>> The current published version of the coding standard has section "5.1.1.2
>> Horizontal Spacing".  In fact, rule 3 of section 5.1.1.2 prohibits spaces
>> between unary operators and their object.  A type cast is a unary operator.
>>  "3.  Do not put space between unary operators and their object."
>
>I should be happy about this (because it *seems* to address what I'd
>like to see), but in fact, the cast operator is not a unary operator. (I
>had double-checked the C standard before sending my earlier email that I
>referenced in this thread.)
>
>Namely, in C99 / 6.5 Expressions, there is:
>
>- 6.5.3 Unary operators
>  - 6.5.3.1 Prefix increment and decrement operators
>  - 6.5.3.2 Address and indirection operators
>  - 6.5.3.3 Unary arithmetic operators
>  - 6.5.3.4 The sizeof operator (*)
>- 6.5.4 Cast operators
>
>And the grammar given under "6.5.4 Cast operators" is:
>
>  cast-expression:
>unary-expression
>( type-name ) cast-expression
>
>Therefore cast operators are not part of the unary operators, neither by
>the structuring of the standard, nor by the official language grammar.
>
>The same can be found in C11, and in C89 as well. (In C89, the section
>numbers are a bit different.)
>
>
>(*) Another, independent, thing that people frequently miss is that the
>parentheses are not part of the sizeof operator. They may be part of the
>*operand* of the sizeof operator. The standard says,
>
>The sizeof operator yields the size (in bytes) of its operand,
>which may be an expression or the parenthesized name of a type.
>
>I consistently write "sizeof variable" and "sizeof *pointer", without
>parens. Thankfully it is not forbidden by the edk2 coding style, and I
>have never received negative comments for it. I shall be watching the
>spec so that this (valid) practice remain accepted. :)
>
>Thanks!
>Laszlo
>
>
>>
>> Sincerely,
>> Daryl McDaniel
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Thursday, November 05, 2015 4:28 AM
>> To: Jarlstrom, Laurie 
>> Cc: Bruce Cran ; edk2-devel@lists.01.org
>> ; Sheng, Cecil (HPS SW) 
>> Subject: Re: [edk2] C Coding Standards Specification disappeared
>>
>> On 11/04/15 18:30, Jarlstrom, Laurie wrote:
>>> Here is a link to a Draft to the 2.1 version :
>>
>https://sourceforge.net/projects/edk2/files/Specifications/CCS_2_1_Draft.pdf
>> /download
>>
>> Is there a semi-formal way to provide input for this spec?
>>
>> Please see:
>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/1881/focus=1889
>>
>> Thank you,
>> Laszlo
>>
>>>
>>> thanks,
>>> Laurie
>>>
>>> laurie.jarlst...@intel.com
>>>
>>> Intel SSG/STO/EBP
>>> (503) 712-9395
>>>
>>>
>>>
>>> -Original Message-
>>> From: Bruce Cran [mailto:br...@cran.org.uk]
>>> Sent: Wednesday, November 04, 2015 8:54 AM
>>> To: Jarlstrom, Laurie; Sheng, Cecil (HPS SW); edk2-devel@lists.01.org
>>> Subject: Re: [edk2] C Coding Standards Specification disappeared
>>>
>>> On 11/4/15 9:44 AM, Jarlstrom, Laurie wrote:
 The Previous C Coding Standards Guide is currently being updated.  A
>new
>> revision will be posted shortly.
>>>
>>> Could someone post that information on the website please?
>>>
>>> By 'website' I guess I mean both the sourceforge _and_ github wikis, since
>> for some reason they're both active.
>>>
>>>
>>
>> ___
>> 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 18/41] OvmfPkg: select LocalApicLib instance with x2apic support if SMM_REQUIRE

[Kinney, Michael D]

Laszlo,

BaseXApicX2ApicLib is intended to be used by platforms that support more >=256 
CPUs.

If the current system configuration is < 256 CPUs, then the platform will 
typically stay in APIC mode.  If >= 256 CPUs are detected, then X2 APIC mode 
can be enabled using the following API.

VOID
EFIAPI
SetApicMode (
  IN UINTN  ApicMode
  )

So just adding BaseXApicX2ApicLib to the DSC does not enable X2 APIC mode.  You 
have to add logic to enable X2 APIC mode.

I see that QEMU is limited to 255 VCPUs, so the use of BaseXApicLib makes 
sense.  Are OVMF configurations supported with >= 256 VCPUs?

Thanks,

Mike

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Wednesday, November 04, 2015 2:41 AM
>To: Paolo Bonzini; edk2-de...@ml01.01.org; Kinney, Michael D; Fan, Jeff;
>Justen, Jordan L
>Subject: Re: [edk2] [PATCH v4 18/41] OvmfPkg: select LocalApicLib instance
>with x2apic support if SMM_REQUIRE
>
>On 11/04/15 09:48, Paolo Bonzini wrote:
>>
>>
>> On 03/11/2015 22:00, Laszlo Ersek wrote:
>>> +
>>> +!if $(SMM_REQUIRE) == TRUE
>>> +
>LocalApicLib|UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
>>> +!else
>>>LocalApicLib|UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
>>> +!endif
>>> +
>>
>> Can we enable BaseXApicX2ApicLib unconditionally?
>
>I think I am technically capable of that :), but should we? We haven't
>used BaseXApicX2ApicLib thus far in OVMF, so I can't predict at all if
>it could regress stuff or not. If it causes problems with the
>SMM_REQUIRE build, so be it, that's new stuff, but I wanted to avoid
>such a global change for the traditional build.
>
>I'm not against it, I just don't have experience with BaseXApicX2ApicLib.
>
>Mike, Jeff, Jordan -- what do you think? Why do separate BaseXApicLib
>and BaseXApicX2ApicLib instances exist? And why has OvmfPkg always used
>the former? If it has only been for simplicity's sake, and
>BaseXApicX2ApicLib is otherwise widely used internally at Intel, then I
>think Paolo is right, and we should just keep the OVMF DSCs simple.
>
>Thanks
>Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

[Kinney, Michael D]

Jiewen,

Yes.  That is a longer term goal for the PiSmmCpuDxeSmm.  Making the GDTs 
consistent helps debug and is a fix that works until we can add logic to 
PiSmmCpuiDxeSmm to inherit current GDT information and use it throughout this 
module.

Thanks,

Mike

>-Original Message-
>From: Yao, Jiewen
>Sent: Friday, October 30, 2015 7:18 AM
>To: Laszlo Ersek; Kinney, Michael D; Fan, Jeff
>Cc: Justen, Jordan L; edk2-devel-01
>Subject: RE: [edk2] about the SMM_S3_RESUME_SMM_64 branch in
>S3Resume2Pei
>
>Yes, first, thanks the great analysis from Laszlo.
>
>Is that possible to eliminate the assumption by parsing current GDT entry?
>
>Instead of hardcode 0x38 or 0x28, if PiSmmCpu inherits GDT from other
>module, should it parse GDT to get correct long mode segment?
>
>I do not object the idea to change DxeCpu driver. I'm just thinking if we have
>robust way to prevent error happening again... if DxeCpu driver is not written
>by us.
>
>Thank you
>Yao Jiewen
>
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Friday, October 30, 2015 4:56 AM
>To: Kinney, Michael D; Yao, Jiewen; Fan, Jeff
>Cc: Justen, Jordan L; edk2-devel-01
>Subject: Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in
>S3Resume2Pei
>
>On 10/29/15 18:30, Kinney, Michael D wrote:
>> Laszlo,
>>
>> Thanks for the very detailed and complete root cause on this issue.
>> I agree that the change you suggest is functional, but I am going to
>> recommend a different solution.
>>
>> Unfortunately, there are several modules that set up a GDT and it is
>> easier from an implementation perspective and for debugging if all the
>> modules agree to use the same GDT layout.  It would be even better if
>> no modules make any assumptions about GDT layouts, but that is a
>> bigger change that we can tackle later.
>>
>> The root cause of this specific issue is that the GDT that is set up
>> by MdeModulePkg/Core/DxeIplPeim is not the same GDT that is set up by
>> UefiCpuPkg /CpuDxe.  And the UefiCpuPkg/PiSmmCpuDxeSmm module has
>some
>> assumptions that the GDT is the one setup by
>> MdeModulePkg/Core/DxeIplPeim.  I recommend we update
>UefiCpuPkg/CpuDxe
>> to use the same GDT layout as MdeModulePkg/Core/DxeIplPeim and then
>> the changes you found worked for PiSmmCpuDxeSmm are not required.
>>
>> I will work on a patch for you to test.
>
>I agree this is the best solution. (I didn't know which one of CpuDxe and
>DxeIplPeim should prevail in dictating the GDT convention, so I didn't suggest
>any unification like this.)
>
>Thanks!
>Laszlo
>
>>
>> Mike
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>>> Of Laszlo Ersek
>>> Sent: Thursday, October 29, 2015 9:19 AM
>>> To: Yao, Jiewen; Kinney, Michael D; Fan, Jeff
>>> Cc: Justen, Jordan L; edk2-devel-01
>>> Subject: Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in
>>> S3Resume2Pei
>>>
>>> Hi Jiewen,
>>>
>>> On 10/29/15 03:28, Yao, Jiewen wrote:
>>>> Thanks for the info. I think we might have to dig out why LONG_JUMP
>>>> fail
>>> here.
>>>> Most our IA BIOS support Ia32X64 mode, so I am sure it should work.
>>>
>>> I think I have found the bug.
>>>
>>> (1)
>>> I added a debug patch to OvmfPkg/QuarkPort/CpuS3DataDxe. I'm
>>> attaching it for illustration. The debug patch dumps the following
>information:
>>> - the location of the GDT descriptor (that gets loaded into the GDT
>>> register)
>>> - the contents of the GDT descriptor (i.e., the base and limit of the
>>> global descriptor table)
>>> - the contents of the GDT entries (the individual segment
>>> descriptors)
>>>
>>> CpuS3DataDxe saves these in AcpiNVS. Later they are saved by
>>>PiSmmCpuDxeSmm from AcpiNVS to SMRAM (during boot), and then
>restored
>>>from SMRAM to AcpiNVS (during S3 Resume).
>>>
>>> The patch dumps these details when the preparation for
>>> PiSmmCpuDxeSmm, in AcpiNVS, is ready.
>>>
>>> Here's the debug output:
>>>
>>> SaveCpuS3Data: 350: GDT descriptor at 0x7E3E2050
>>> SaveCpuS3Data: 353: GDT Base=0x7F706000 Limit=0x3F
>>> SaveCpuS3Data: 363: Idx=0x00 Base=0x Limit=0x
>>> Type=0x0
>>> System=0x0 Dpl=0x0 Present=0x0 Software=0x0 LCodeSeg=0x0
>>> DefaultSize=0x0
>>> SaveCpuS3Data: 363: Idx=0x08 Base=0x Li

Re: [edk2] [Patch] BaseTools: Print PACKAGES_PATH build environment if it is set.

[Kinney, Michael D]

Liming,

I agree with that algorithm that the display format is the same.

Still make the code hard to understand.  Please add comments that explain that 
PACKAGES_PATH and EDK_TOOLS_BIN require extra processing to provide the same 
display format as the other environment variables that have already been 
updated is os.environ. 

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

Mike

>-Original Message-
>From: Gao, Liming
>Sent: Thursday, November 05, 2015 5:30 PM
>To: Kinney, Michael D; edk2-devel@lists.01.org
>Subject: RE: [edk2] [Patch] BaseTools: Print PACKAGES_PATH build
>environment if it is set.
>
>Mike:
>  In Build.py, after it converts WorkspaceDir, it also set it into its
>os.environ["WORKSPACE"]. And, I verify this patch that prints the same style
>for those envs.
>
>WorkspaceDir =
>os.path.normcase(os.path.normpath(os.environ["WORKSPACE"]))
>if not os.path.exists(WorkspaceDir):
>EdkLogger.error("build", FILE_NOT_FOUND, "WORKSPACE doesn't exist",
>ExtraData="%s" % WorkspaceDir)
>elif ' ' in WorkspaceDir:
>EdkLogger.error("build", FORMAT_NOT_SUPPORTED, "No space is allowed
>in WORKSPACE path",
>            ExtraData=WorkspaceDir)
>os.environ["WORKSPACE"] = WorkspaceDir
>
>Thanks
>Liming
>-Original Message-
>From: Kinney, Michael D
>Sent: Friday, November 06, 2015 9:14 AM
>To: Gao, Liming; edk2-devel@lists.01.org; Kinney, Michael D
>Subject: RE: [edk2] [Patch] BaseTools: Print PACKAGES_PATH build
>environment if it is set.
>
>Liming,
>
>That is the assignment of a Python variable WorkspaceDir, but the lines to do
>prints are not consistent.
>
>EdkLogger.quiet("%-16s = %s" % ("WORKSPACE",os.environ["WORKSPACE"]))
>EdkLogger.quiet("%-16s = %s" % ("PACKAGES_PATH",
>os.path.normcase(os.path.normpath(os.environ["PACKAGES_PATH"]
>
>Mike
>
>>-Original Message-
>>From: Gao, Liming
>>Sent: Thursday, November 05, 2015 4:58 PM
>>To: Kinney, Michael D; edk2-devel@lists.01.org
>>Cc: Gao, Liming
>>Subject: RE: [edk2] [Patch] BaseTools: Print PACKAGES_PATH build
>>environment if it is set.
>>
>>Mike:
>>  WORKSPACE env has been converted in the previous logic. Build.py line
>>101,  WorkspaceDir =
>>os.path.normcase(os.path.normpath(os.environ["WORKSPACE"])).
>>  Here, I convert PACKAGES_PATH and EDK_TOOLS_BIN to be consistent
>>print style with WORKSPACE env.
>>
>>Thanks
>>Liming
>>-Original Message-
>>From: Kinney, Michael D
>>Sent: Thursday, November 05, 2015 7:46 AM
>>To: Gao, Liming; edk2-devel@lists.01.org; Kinney, Michael D
>>Subject: RE: [edk2] [Patch] BaseTools: Print PACKAGES_PATH build
>>environment if it is set.
>>
>>Liming,
>>
>>Why do you a different method than WORKSPACE to display the
>>PACKAGES_PATH and EDK_TOOLS_BIN environment variables?
>>
>>Thanks,
>>
>>Mike
>>
>>>-Original Message-
>>>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>>Liming Gao
>>>Sent: Tuesday, November 03, 2015 5:15 PM
>>>To: edk2-devel@lists.01.org
>>>Subject: [edk2] [Patch] BaseTools: Print PACKAGES_PATH build
>>>environment if it is set.
>>>
>>>Print the optional build environment PACKAGES_PATH and
>EDK_TOOLS_BIN.
>>>
>>>Contributed-under: TianoCore Contribution Agreement 1.0
>>>Signed-off-by: Liming Gao <liming@intel.com>
>>>---
>>> BaseTools/Source/Python/build/build.py | 4 
>>> 1 file changed, 4 insertions(+)
>>>
>>>diff --git a/BaseTools/Source/Python/build/build.py
>>>b/BaseTools/Source/Python/build/build.py
>>>index 30ff5bb..67bd3b3 100644
>>>--- a/BaseTools/Source/Python/build/build.py
>>>+++ b/BaseTools/Source/Python/build/build.py
>>>@@ -780,10 +780,14 @@ class Build():
>>>
>>> # print current build environment and configuration
>>> EdkLogger.quiet("%-16s = %s" % ("WORKSPACE",
>>>os.environ["WORKSPACE"]))
>>>+if "PACKAGES_PATH" in os.environ:
>>>+EdkLogger.quiet("%-16s = %s" % ("PACKAGES_PATH",
>>>os.path.normcase(os.path.normpath(os.environ["PACKAGES_PATH"]>>
>EdkLogger.quiet("%-16s = %s" % ("ECP_SOURCE",
>>>os.environ["ECP_SOURCE"]))
>>> EdkLogger.quiet("%-16s = %s" % ("EDK_SOURCE",
>>>os.environ["EDK_SOURCE"]))
>>> EdkLogger.quiet("%-16s = %s" % ("EFI_SOURCE",
>>>os.environ["EFI_SOURCE"]))
>>> EdkLogger.quiet("%-16s = %s" % ("EDK_TOOLS_PATH",
>>>os.environ["EDK_TOOLS_PATH"]))
>>>+if "EDK_TOOLS_BIN" in os.environ:
>>>+EdkLogger.quiet("%-16s = %s" % ("EDK_TOOLS_BIN",
>>>os.path.normcase(os.path.normpath(os.environ["EDK_TOOLS_BIN"]
>>>
>>> EdkLogger.info("")
>>>
>>>--
>>>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] BaseTools: Print PACKAGES_PATH build environment if it is set.

[Kinney, Michael D]

Liming, 

That is the assignment of a Python variable WorkspaceDir, but the lines to do 
prints are not consistent.

EdkLogger.quiet("%-16s = %s" % ("WORKSPACE",os.environ["WORKSPACE"]))
EdkLogger.quiet("%-16s = %s" % ("PACKAGES_PATH", 
os.path.normcase(os.path.normpath(os.environ["PACKAGES_PATH"]

Mike

>-Original Message-
>From: Gao, Liming
>Sent: Thursday, November 05, 2015 4:58 PM
>To: Kinney, Michael D; edk2-devel@lists.01.org
>Cc: Gao, Liming
>Subject: RE: [edk2] [Patch] BaseTools: Print PACKAGES_PATH build
>environment if it is set.
>
>Mike:
>  WORKSPACE env has been converted in the previous logic. Build.py line 101,
> WorkspaceDir =
>os.path.normcase(os.path.normpath(os.environ["WORKSPACE"])).
>  Here, I convert PACKAGES_PATH and EDK_TOOLS_BIN to be consistent print
>style with WORKSPACE env.
>
>Thanks
>Liming
>-Original Message-
>From: Kinney, Michael D
>Sent: Thursday, November 05, 2015 7:46 AM
>To: Gao, Liming; edk2-devel@lists.01.org; Kinney, Michael D
>Subject: RE: [edk2] [Patch] BaseTools: Print PACKAGES_PATH build
>environment if it is set.
>
>Liming,
>
>Why do you a different method than WORKSPACE to display the
>PACKAGES_PATH and EDK_TOOLS_BIN environment variables?
>
>Thanks,
>
>Mike
>
>>-Original Message-
>>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>Liming Gao
>>Sent: Tuesday, November 03, 2015 5:15 PM
>>To: edk2-devel@lists.01.org
>>Subject: [edk2] [Patch] BaseTools: Print PACKAGES_PATH build
>>environment if it is set.
>>
>>Print the optional build environment PACKAGES_PATH and EDK_TOOLS_BIN.
>>
>>Contributed-under: TianoCore Contribution Agreement 1.0
>>Signed-off-by: Liming Gao <liming@intel.com>
>>---
>> BaseTools/Source/Python/build/build.py | 4 
>> 1 file changed, 4 insertions(+)
>>
>>diff --git a/BaseTools/Source/Python/build/build.py
>>b/BaseTools/Source/Python/build/build.py
>>index 30ff5bb..67bd3b3 100644
>>--- a/BaseTools/Source/Python/build/build.py
>>+++ b/BaseTools/Source/Python/build/build.py
>>@@ -780,10 +780,14 @@ class Build():
>>
>> # print current build environment and configuration
>> EdkLogger.quiet("%-16s = %s" % ("WORKSPACE",
>>os.environ["WORKSPACE"]))
>>+if "PACKAGES_PATH" in os.environ:
>>+EdkLogger.quiet("%-16s = %s" % ("PACKAGES_PATH",
>>os.path.normcase(os.path.normpath(os.environ["PACKAGES_PATH"]>> 
>>EdkLogger.quiet("%-16s = %s" % ("ECP_SOURCE",
>>os.environ["ECP_SOURCE"]))
>> EdkLogger.quiet("%-16s = %s" % ("EDK_SOURCE",
>>os.environ["EDK_SOURCE"]))
>> EdkLogger.quiet("%-16s = %s" % ("EFI_SOURCE",
>>os.environ["EFI_SOURCE"]))
>> EdkLogger.quiet("%-16s = %s" % ("EDK_TOOLS_PATH",
>>os.environ["EDK_TOOLS_PATH"]))
>>+if "EDK_TOOLS_BIN" in os.environ:
>>+EdkLogger.quiet("%-16s = %s" % ("EDK_TOOLS_BIN",
>>os.path.normcase(os.path.normpath(os.environ["EDK_TOOLS_BIN"]
>>
>> EdkLogger.info("")
>>
>>--
>>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 v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

[Kinney, Michael D]

Laszlo,

Thanks for the details.  Your implementation looks good.

I will discuss this further with Jiewen to see if it makes sense to provide 
additional implementations of this PPI that could be shared by multiple 
platforms.

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Thursday, November 05, 2015 3:15 AM
>To: Kinney, Michael D; edk2-de...@ml01.01.org
>Cc: Justen, Jordan L
>Subject: Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-
>as-SMRAM during PEI
>
>On 11/05/15 02:32, Kinney, Michael D wrote:
>> Laszlo,
>>
>> For the EFI_PEI_COMMUNICATION_PPI, is there a reason you are not using
>> UefiCpuPkg\PiSmmCommunication\PiSmmCommunicationPei.inf to produce
>that PPI?
>
>Yes.
>
>When I wrote this patch originally on April 27th and the days after,
>there was no EFI_PEI_COMMUNICATION_PPI implementation in edk2; neither
>were plans known to add one.
>
>In addition, we had discussed the behavior of SmmLockBoxPeiLib at
>length, in an off-list thread that you had been CC'd on. Please search
>your archives for the message with the following metadata, and the
>sub-thread rooted in it:
>
>Message-ID: <553f96cc.9050...@redhat.com>
>Date:   Tue, 28 Apr 2015 16:18:52 +0200
>From:   Laszlo Ersek <ler...@redhat.com>
>To: Yao, Jiewen <jiewen@intel.com>
>CC:     Justen, Jordan L <jordan.l.jus...@intel.com>,
>Zimmer, Vincent <vincent.zim...@intel.com>,
>Kinney, Michael D <michael.d.kin...@intel.com>,
>Paolo Bonzini <pbonz...@redhat.com>,
>Gerd Hoffmann <kra...@redhat.com>,
>Michael S. Tsirkin <m...@redhat.com>
>Subject:Re: open-sourcing Intel's "IA32FamilyCpuPkg/PiSmmCpuDxeSmm"
>
>In that message, I asked:
>
>> In the whitepaper entitled "A Tour Beyond BIOS: Implementing S3 Resume
>> with EDKII", page 25 says, under the heading "PEI Instance":
>>
>> The PEI instance of SmmLockboxLib has two ways to communicate with
>> the LockBox in SMRAM.
>>
>> 1) It uses the SMM_COMMUNICATION PPI to communicate the SmmLockbox
>> service provider, similar as DXE instance.
>> 2) When the PEI instance is used before SMM ready, the
>> SMM_COMMUNICATION PPI will return EFI_NOT_STARTED. In this case,
>> PEI SmmLockBoxLib needs to search the SMRAM region directly to
>> find LockBox content.
>>
>> The question is why a platform would choose option (1), ever.
>>
>> Namely, option (1) depends on additional drivers:
>> - SMM_COMMUNICATION_PPI that actually works
>> - (which might further depend on PEI_SMM_CONTROL_PPI)
>> - a PEIM driver that implements the privileged (SMM) half of lockbox
>>
>> Whereas, option (2) is much simpler for the platform. It just needs to
>> provide a minimal SMM_COMMUNICATION_PPI where it always returns
>> EFI_NOT_STARTED. Then the lockbox library will do everything (and
>> depend only on PEI_SMM_ACCESS_PPI).
>>
>> So, the question is: why would a platform ever pick (1), given that it
>> is much more work to implement, for (as far as I can see) no benefit?
>
>And Jiewen replied (the same day),
>
>> Ah, I see. The only reason is that: A PEIM might need to restore
>> lockbox data *before* SMM rebase happen. Then it has to use #2.
>>
>> A PEIM might need to restore lockbox data *after* SMM rebase happen.
>> Then it has to use #1. (Scanning SMRAM does not work at that moment,
>> which is enforced by SMRR)
>
>I couldn't see any grounds from Jiewen's answer to abandon option (2).
>Option (2) actually worked, plus it was actually the *only* possibility
>to make SmmLockboxLib work in OVMF (see above).
>
>I would like to stick with this approach.
>
>Thanks
>Laszlo
>
>>
>> Thanks,
>>
>> Mike
>>
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Tuesday, November 03, 2015 1:01 PM
>>> To: edk2-de...@ml01.01.org
>>> Cc: Kinney, Michael D; Justen, Jordan L
>>> Subject: [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-
>SMRAM
>>> during PEI
>>>
>>> "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the
>library
>>> instance that implements the LockBoxLib library class with SMRAM access
>>> for the PEI phase.
>>>
>>> Introduce a PEIM that produces the EFI_PEI_SMM_COMMUNICATION_PPI
>and
>>> PEI_SMM_ACCESS_PPI interfaces, enabling SmmLockBoxPeiLib to work.
>>>

Re: [edk2] C Coding Standards Specification disappeared

[Kinney, Michael D]

Laszlo,

The semi-formal way is to discuss these types of change requests on this 
mailing list and get agreement.

I think your suggestion to add a new horizontal spacing rule that there should 
be no space between cast operator and cast operand is good.

I will collect results of these discussions and get new versions of the 
document released.

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Thursday, November 05, 2015 4:28 AM
>To: Jarlstrom, Laurie
>Cc: Bruce Cran; edk2-devel@lists.01.org; Sheng, Cecil (HPS SW)
>Subject: Re: [edk2] C Coding Standards Specification disappeared
>
>On 11/04/15 18:30, Jarlstrom, Laurie wrote:
>> Here is a link to a Draft to the 2.1 version :
>https://sourceforge.net/projects/edk2/files/Specifications/CCS_2_1_Draft.pdf/
>download
>
>Is there a semi-formal way to provide input for this spec?
>
>Please see:
>http://thread.gmane.org/gmane.comp.bios.edk2.devel/1881/focus=1889
>
>Thank you,
>Laszlo
>
>>
>> thanks,
>> Laurie
>>
>> laurie.jarlst...@intel.com
>>
>> Intel SSG/STO/EBP
>> (503) 712-9395
>>
>>
>>
>> -Original Message-
>> From: Bruce Cran [mailto:br...@cran.org.uk]
>> Sent: Wednesday, November 04, 2015 8:54 AM
>> To: Jarlstrom, Laurie; Sheng, Cecil (HPS SW); edk2-devel@lists.01.org
>> Subject: Re: [edk2] C Coding Standards Specification disappeared
>>
>> On 11/4/15 9:44 AM, Jarlstrom, Laurie wrote:
>>> The Previous C Coding Standards Guide is currently being updated.  A new
>revision will be posted shortly.
>>
>> Could someone post that information on the website please?
>>
>> By 'website' I guess I mean both the sourceforge _and_ github wikis, since
>for some reason they're both active.
>>
>>
>
>___
>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] ArmPkg/BdsLib: Increase fallback tftp buffer size

[Kinney, Michael D]

Hi,

There are macros in MdePkg/Include/Base.h that help align values and pointers 
to the next boundary.  
This patch could use the following:

TftpBufferSize = ALIGN_VALUE (TftpBufferSize, SIZE_16MB);

/**
  Rounds a value up to the next boundary using a specified alignment.

  This function rounds Value up to the next boundary using the specified 
Alignment.
  This aligned value is returned.

  @param   Value  The value to round up.
  @param   Alignment  The alignment boundary used to return the aligned value.

  @return  A value up to the next boundary.

**/
#define ALIGN_VALUE(Value, Alignment) ((Value) + (((Alignment) - (Value)) & 
((Alignment) - 1)))

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Ashutosh Singh
>Sent: Friday, November 06, 2015 9:01 AM
>To: edk2-de...@ml01.01.org
>Cc: ryan.har...@linaro.org; ler...@redhat.com; james.k...@arm.com;
>leif.lindh...@linaro.org; ashutosh.si...@arm.com
>Subject: [edk2] [PATCH] ArmPkg/BdsLib: Increase fallback tftp buffer size
>
>When performing a tftp download from a server which does not support
>rfc2349 transfer size option (such as netkit-tftpd), the existing code
>falls back to allocating an 8MB buffer. Since this is insufficient for
>an uncompressed AArch64 Linux kernel image, double the size to 16MB.
>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Ashutosh Singh 
>---
> ArmPkg/Library/BdsLib/BdsFilePath.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/ArmPkg/Library/BdsLib/BdsFilePath.c
>b/ArmPkg/Library/BdsLib/BdsFilePath.c
>index ff42175..0410236 100644
>--- a/ArmPkg/Library/BdsLib/BdsFilePath.c
>+++ b/ArmPkg/Library/BdsLib/BdsFilePath.c
>@@ -1198,7 +1198,7 @@ BdsTftpLoadImage (
>   if (Mtftp4GetFileSize (Mtftp4, AsciiFilePath, ) == EFI_SUCCESS) {
> TftpBufferSize = FileSize;
>   } else {
>-TftpBufferSize = SIZE_8MB;
>+TftpBufferSize = SIZE_16MB;
>   }
>
>   TftpContext = AllocatePool (sizeof (BDS_TFTP_CONTEXT));
>@@ -1209,7 +1209,7 @@ BdsTftpLoadImage (
>   TftpContext->FileSize = FileSize;
>
>   for (; TftpBufferSize <= FixedPcdGet32 (PcdMaxTftpFileSize);
>- TftpBufferSize = (TftpBufferSize + SIZE_8MB) & (~(SIZE_8MB-1))) {
>+ TftpBufferSize = (TftpBufferSize + SIZE_16MB) & (~(SIZE_16MB-1))) {
> //
> // Allocate a buffer to hold the whole file.
> //
>--
>1.7.9.5
>
>
>
>
>-- IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended recipient,
>please notify the sender immediately and do not disclose the contents to any
>other person, use it for any purpose, or store or copy the information in any
>medium. Thank you.
>
>___
>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 51/52] OvmfPkg: double the SMRAM (TSEG) size for the 64-bit DXE phase builds

[Kinney, Michael D]

Laszlo,

The PCD setting for TSEG size needs to be set for both IA32 and X64 modules in 
OvmfPkg/OvmfPkgIa32X64.dsc.
The this current patch, TSEG PCD is set to DEC default value for PEIMs of 1MB 
and 2MB for DXE/SMM phase.  
This causes SMM Core to only see 1MB SMRAM area.

I found this when trying to verify large number of VCPUs with 
OvmfPkg/OvmfPkgIa32X64.dsc build.

In order to test large VCPU numbers, we may also want to increase SMRAM size to 
more than 2 MB.

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Wednesday, October 14, 2015 3:27 PM
>To: edk2-de...@ml01.01.org
>Subject: [edk2] [PATCH v3 51/52] OvmfPkg: double the SMRAM (TSEG) size for
>the 64-bit DXE phase builds
>
>When building OVMF with -D SMM_REQUIRE -D SECURE_BOOT_ENABLE, using
>gcc-4.8, for the DEBUG build target, and with DEBUG_VERBOSE enabled in
>PcdDebugPrintErrorLevel, the build report files report the following
>binary sizes for the SMM_CORE and SMM modules, in kilobytes:
>
>  Driver  Ia32  X64
>    --  ---
>  PiSmmCore  56.7598.22
>  CpuIo2Smm  13.4722.72
>  SmmLockBox 24.6239.69
>  PiSmmCpuDxeSmm 66.06   123.03
>  FvbServicesSmm 22.2237.06
>  SmmFaultTolerantWriteDxe   35.1960.06
>  VariableSmm   356.88   640.28
>    --  ---
>  Total 575.19  1021.06
>
>The 1 MB default for PcdQ35TsegMbytes, from OvmfPkg.dec, is insufficient
>for loading the privileged half of the variable driver (VariableSmm) on
>X64. This results in many warnings about the dependent drivers being
>impossible to dispatch, and ultimately a DXE core assertion failure.
>
>PcdQ35TsegMbytes can assume the values 1, 2 or 8; set it to 2 for the DSC
>files with 64-bit DXE phases. For consistency between the DSC files, spell
>out 1 in OvmfPkgIa32.dsc too.
>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Laszlo Ersek 
>---
>
>Notes:
>v3:
>- new in v3
>
> OvmfPkg/OvmfPkgIa32.dsc| 1 +
> OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
> OvmfPkg/OvmfPkgX64.dsc | 1 +
> 3 files changed, 3 insertions(+)
>
>diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>index 9040bdc..660a645 100644
>--- a/OvmfPkg/OvmfPkgIa32.dsc
>+++ b/OvmfPkg/OvmfPkgIa32.dsc
>@@ -401,6 +401,7 @@ [PcdsFixedAtBuild]
>
> !if $(SMM_REQUIRE) == TRUE
>   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
>+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|1
> !endif
>
> !if $(SECURE_BOOT_ENABLE) == TRUE
>diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>index 4aa7ba5..16dd785 100644
>--- a/OvmfPkg/OvmfPkgIa32X64.dsc
>+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>@@ -407,6 +407,7 @@ [PcdsFixedAtBuild]
> [PcdsFixedAtBuild.X64]
> !if $(SMM_REQUIRE) == TRUE
>   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
>+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|2
> !endif

Move PcdQ35TsegMbytes setting above [PcdsFixedAtBuild.X64] 

!if $(SMM_REQUIRE) == TRUE
  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes |2
!endif

[PcdsFixedAtBuild.X64]
!if $(SMM_REQUIRE) == TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
!endif

>
> !if $(SECURE_BOOT_ENABLE) == TRUE
>diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>index 6ea135d..fe4889a 100644
>--- a/OvmfPkg/OvmfPkgX64.dsc
>+++ b/OvmfPkg/OvmfPkgX64.dsc
>@@ -406,6 +406,7 @@ [PcdsFixedAtBuild]
>
> !if $(SMM_REQUIRE) == TRUE
>   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
>+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|2
> !endif
>
> !if $(SECURE_BOOT_ENABLE) == TRUE
>--
>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 v3 04/52] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

[Kinney, Michael D]

Laszlo,

Here is a proposed fix on top of your v3 patch services to address a race 
condition that was introduced by the v3 patch series call to StartupAllAPs() 
with SingleThread set to TRUE in the MP initialization.  If the APs have not 
entered their idle loop before StartupAllAPs() is called, then some of the APs 
will be in an unexpected state, and StartupAllAPs() will hang.  This is the 
hang condition that is only seen when SingleThread parameter is set to TRUE and 
StartupAllAPs() is called very shortly after mAPsAlreadyInitFinished is set to 
TRUE that releases the APs to complete their initialization.

I added an internal function that checks to see if all APs are in the sleeping 
state in the idle loop.  On the first call to StartupAllAPs(), this internal 
function is used to make sure the APs are in a state that is compatible with 
StartupAllAPs() being used.  I put this check in the first call to 
StartupAllAPs(), so we do not take the delay to wait for the APs 
unconditionally in the MP init code.  Other work can get done while the APs 
work their way to their idle loop sleeping state.  

The one item remaining is to have a timeout with an ASSERT() if timeout is 
triggered in first call to StartupAllAPs() waiting for the APs to enter idle 
loop. 

I also reordered some of the actions InitializeMpSupport(), so the MP Services 
Protocol and call to StartupAllAPs() are done as late as possible to give APs 
more time to get to idle loop. 

Please merge this into your patch series.

Best regards,

Mike


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


24d1f93110e1f73c70ff3705950c119693328deb
 UefiCpuPkg/CpuDxe/CpuMp.c | 93 ++-
 1 file changed, 75 insertions(+), 18 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index fbe43f5..4af0361 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -29,6 +29,7 @@ VOID *mApStackStart = 0;
 
 volatile BOOLEAN mAPsAlreadyInitFinished = FALSE;
 volatile BOOLEAN mStopCheckAllAPsStatus = TRUE;
+BOOLEAN  mStartupAllAPsCalled= FALSE;
 
 EFI_MP_SERVICES_PROTOCOL  mMpServicesTemplate = {
   GetNumberOfProcessors,
@@ -313,6 +314,47 @@ CheckAndUpdateAllAPsToIdleState (
 }
 
 /**
+  Check if all APs are in state CpuStateSleeping.
+  
+  Return TRUE if all APs are in the CpuStateSleeping state.  Do not 
+  check the state of the BSP or any disabled APs.
+
+  @retval TRUE   All APs are in CpuStateSleeping state.
+  @retval FALSE  One or more APs are not in CpuStateSleeping state.
+  
+**/
+BOOLEAN
+CheckAllAPsSleeping (
+  VOID
+  )
+{
+  UINTN   ProcessorNumber;
+  CPU_DATA_BLOCK  *CpuData;
+
+  for (ProcessorNumber = 0; ProcessorNumber < 
mMpSystemData.NumberOfProcessors; ProcessorNumber++) {
+CpuData = [ProcessorNumber];
+if (TestCpuStatusFlag (CpuData, PROCESSOR_AS_BSP_BIT)) {
+  //
+  // Skip BSP
+  //
+  continue;
+}
+
+if (!TestCpuStatusFlag (CpuData, PROCESSOR_ENABLED_BIT)) {
+  //
+  // Skip Disabled processors
+  //
+  continue;
+}
+
+if (GetApState (CpuData) != CpuStateSleeping) {
+  return FALSE;
+}
+  }
+  return TRUE;
+}  
+
+/**
   If the timeout expires before all APs returns from Procedure,
   we should forcibly terminate the executing AP and fill FailedList back
   by StartupAllAPs().
@@ -647,6 +689,18 @@ StartupAllAPs (
   //
   mStopCheckAllAPsStatus = TRUE;
 
+  if (!mStartupAllAPsCalled) {
+//
+// If this is first call to StartAllAPs(), then 
+// wait for all APs to enter idle loop.
+//
+while (!CheckAllAPsSleeping ()) {
+  CpuPause();
+}
+  
+mStartupAllAPsCalled = TRUE;
+  }
+
   for (Number = 0; Number < mMpSystemData.NumberOfProcessors; Number++) {
 CpuData = [Number];
 if (TestCpuStatusFlag (CpuData, PROCESSOR_AS_BSP_BIT)) {
@@ -1700,6 +1754,9 @@ InitializeMpSupport (
  sizeof (CPU_DATA_BLOCK) * 
mMpSystemData.NumberOfProcessors,
  mMpSystemData.CpuDatas);
 
+  //
+  // Release all APs to complete initialization and enter idle loop
+  //  
   mAPsAlreadyInitFinished = TRUE;
 
   //
@@ -1707,6 +1764,23 @@ InitializeMpSupport (
   //
   CollectBistDataFromHob ();
 
+  if (mMpSystemData.NumberOfProcessors > 1 && mMpSystemData.NumberOfProcessors 
< gMaxLogicalProcessorNumber) {
+if (mApStackStart != NULL) {
+  FreePages (mApStackStart, EFI_SIZE_TO_PAGES (
+  (gMaxLogicalProcessorNumber - 
mMpSystemData.NumberOfProcessors) *
+  gApStackSize));
+}
+  }
+
+  Status = gBS->CreateEvent (
+  EVT_SIGNAL_EXIT_BOOT_SERVICES,
+  TPL_CALLBACK,
+  ExitBootServicesCallback,
+  NULL,
+  
+  );
+  ASSERT_EFI_ERROR (Status);
+  
   //
   // Synchronize MTRR 

Re: [edk2] SMM core problems

[Kinney, Michael D]

Dimiri,

Can you please clarify what OS move operation is being performed?

Memory ranges of type EfiRuntimeServicesData must remain at the same physical 
address.  When SetVirtualAddressMap() is called, the OS can specify a virtual 
address that is different than the physical address, but the memory can not be 
moved to a different physical address.

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of iMac
>Pro
>Sent: Thursday, October 15, 2015 1:59 AM
>To: edk2-devel@lists.01.org
>Subject: [edk2] SMM core problems
>
>Hi,
>
>Found that problems in PiSmmIpl.c/PiSmmCore.c:
>
>1.  SMM_CORE_PRIVATE_DATA *gSmmCorePrivate  is pointer
>to EfiRuntimeServicesCode (.code and .data segs are merged in x86) memory
>that can be declared as ReadOnly by OS. But
>SmmCommunicationCommunicate
>write to it. GPE in OS !!!
>
>2. EfiRuntimeServicesData memory can be moved by OS loader physically.
>("preserved by the loader" in spec - not means in the same place). So this
>is not best place to store SMM_CORE_PRIVATE_DATA also, because
>PiSmmCore.c.does not know that boot loader moved it.
>
>Best regards,
>Dimitri
>___
>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 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace include

[Kinney, Michael D]

Laszlo,

Good question.  

It is a good practice to have the .h file for each GUID.  The .h file contains 
the extern for the global variable associated with the GUID along with data 
structures associated with the GUID.

For PCD token space GUIDs, there is no data structure and the AutoGen.h file 
contains an extern to all token space GUIDs a module references, so the .h file 
for the token space GUID is not required.

The C name for a Token space GUID (i.e. gUefiCpuPkgTokenSpaceGuid) would be 
required in C code if the PcdLib PcdGetEx8 (),PcdGetEx16 (),PcdGetEx32 
(),PcdGetEx64 (),PcdGetExBool (),or PcdGetExPtr () APIs are used.  Most 
modules/libs do not use the 'Ex' versions of these, so it is very rare for a 
module to use the C name for a Token space GUID.

I will remove the UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h from the patch 
set.

Thanks,

Mike

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, October 07, 2015 10:38 AM
To: Kinney, Michael D; edk2-de...@ml01.01.org
Subject: Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace 
include

On 10/05/15 01:57, Michael Kinney wrote:
> Add missing include files for the token space GUID for the UefiCpuPkg
> Add path to the token space include file to the UefiCpuPkg DEC file.

Is this usual? For example, gUefiOvmfPkgTokenSpaceGuid is also not
defined anywhere else than in the DEC file.

What could a programmer use UEFICPUPKG_TOKEN_SPACE_GUID /
gUefiCpuPkgTokenSpaceGuid for, in C source code?

... Only the following packages / header files seem to expose their
respective token space GUIDs in a similar way:

MdeModulePkg/Include/Guid/MdeModulePkgTokenSpace.h
MdePkg/Include/Guid/MdePkgTokenSpace.h
PcAtChipsetPkg/Include/Guid/PcAtChipsetTokenSpace.h
PerformancePkg/Include/Guid/PerformancePkgTokenSpace.h
SecurityPkg/Include/Guid/SecurityPkgTokenSpace.h
ShellPkg/Include/Guid/ShellPkgTokenSpace.h
Vlv2DeviceRefCodePkg/Include/Guid/Vlv2DeviceRefCodePkgTokenSpace.h

Thanks!
Laszlo

> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
> ---
>  UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h | 25 +
>  UefiCpuPkg/UefiCpuPkg.dec  |  1 +
>  2 files changed, 26 insertions(+)
>  create mode 100644 UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
> 
> diff --git a/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h 
> b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
> new file mode 100644
> index 000..6c4e671
> --- /dev/null
> +++ b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
> @@ -0,0 +1,25 @@
> +/** @file
> +GUID for UefiCpuPkg PCD Token Space
> +
> +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
> +
> +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 _UEFICPUPKG_TOKEN_SPACE_GUID_H_
> +#define _UEFICPUPKG_TOKEN_SPACE_GUID_H_
> +
> +#define UEFICPUPKG_TOKEN_SPACE_GUID \
> +  { \
> +0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 
> 0xb0 } \
> +  }
> +
> +extern EFI_GUID gUefiCpuPkgTokenSpaceGuid;
> +
> +#endif
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index e4b8030..e293390 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -51,6 +51,7 @@
>SmmCpuFeaturesLib|Include/Library/SmmCpuFeaturesLib.h
>  
>  [Guids]
> +  ## Include/Guid/UefiCpuPkgTokenSpace.h
>gUefiCpuPkgTokenSpaceGuid  = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 
> 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
>  
>  [Protocols]
> 

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

Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

[Kinney, Michael D]

Hi Laszlo,

Thanks for the feedback!

Please let me know if I missed any of your questions.

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Wednesday, October 07, 2015 10:32 AM
>To: Kinney, Michael D
>Cc: edk2-de...@ml01.01.org
>Subject: Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module
>
>On 10/05/15 01:57, Michael Kinney wrote:
>> Add module that initializes a CPU for the SMM envirnment and
>> installs the first level SMI handler.  This module along with the
>> SMM IPL and SMM Core provide the services required for
>> DXE_SMM_DRIVERS to register hardware and software SMI handlers.
>>
>> CPU specific features are abstracted through the SmmCpuFeaturesLib
>>
>> Platform specific features are abstracted through the
>> SmmCpuPlatformHookLib
>>
>> Several PCDs are added to enable/disable features and configure
>> settings for the PiSmmCpuDxeSmm module
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
>
>(I'm snipping the patch because it is extremely long.)
>
>I'm going through my "QuarkPort" patches, evaluating for each one if I
>should keep it, drop it, or adapt it.
>
>* [PATCH 27/58] OvmfPkg: import PCDs from
>  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
>  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=350
>
>  Going through all the PCDs I had to import there, and checking if each
>  was present in this patch too, I found the following difference:
>
>  PcdCpuSmmUncacheCpuSyncData is absent from this patch. In my
>  "QuarkPort", the PCD is used by the InitializeMpServiceData() function
>  only, gating a call to SetCacheability(). And that call to
>  SetCacheability() is the *only* such call.
>
>  Now, this patch provides SetCacheability(), but no calls are made to
>  it, ever (in accordance with the fact that the PCD that would control
>  the call is also absent).
>
>  (1) Therefore I recommend to delete the SetCacheability() function
>  from this patch.

I agree.  I will remove that function.  I missed that function when I removed
PcdCpuSmmUncacheCpuSyncData.

>
>  (2) I have a question wrt. PcdCpuSmmEnableBspElection. In the Quark
>  package, the "IA32FamilyCpuBasePkg.dsc" file overrides the default
>  TRUE value (from the .dec) for this PCD, with FALSE.
>
>  The .dec default is similarly TRUE here. In my "QuarkPort" for
>  OVMF, I flipped the PCD to FALSE as well. Does that make sense?
>  Should I stick with that override, when rebasing the OVMF SMM
>  series on top of this series? I don't know why this PCD matters.
>  What are the benefits vs. drawbacks of dynamic BSP-for-SMI
>  election?

For OVMF you will likely not see any difference in behavior.  
This PCD allows a platform to provide PlatformSmmBspElection() 
in a  platform specific SmmCpuPlatformHookLib instance to 
decide which CPU gets elected to be the BSP in each SMI.

The SmmCpuPlatformHookLibNull always returns 
EFI_NOT_READY for that function, which makes the 
module behave the same as the PCD being set to FALSE.

The default is TRUE, so the platform lib is always called,
so a platform developer can implement the hook 
function and does not have to also change a PCD
setting for the hook function to be active.

A platform that wants to eliminate the call to the 
hook function all together can set the PCD to FALSE.

So for OVMF, I think it makes sense to set this PCD to
FALSE in the DSC file.

>
>* [PATCH 28/58] OvmfPkg: import three protocols from
>  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
>  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=351
>
>  (3) This patch doesn't install gSmmCpuSyncProtocolGuid or
>  gSmmCpuSync2ProtocolGuid in PiCpuSmmEntry(), whereas Quark does.
>
>  I don't know what those protocols good for, but can you please
>  summarize why this patch doesn't need them?

I did not find any consumers of the Sync protocols, so I removed them.

>
>* [PATCH 32/58] OvmfPkg: QuarkPort: drop ACPI_CPU_DATA.APState
>  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=362
>
>  (4) Patch 5/7 in this series introduces the ACPI_CPU_DATA structure.
>  That structure has a field APState. I think it should be dropped,
>  it is never used in 6/7.

I agree it is not used.  However, this structure is shared between modules
through a buffer address in a PCD, and I am concerned that there may be 
other modules that depend on this layout.  I will need to do more
investigation before I can consider removing it.

>
>* [PATCH 33/58] OvmfPkg: add skeleton QuarkPort/CpuS

Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into RngDxe

[Kinney, Michael D]

LONG, Qin,

Do you know if the 10uS delay required in RdRandGetSeed128()?

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Long,
>Qin
>Sent: Wednesday, October 07, 2015 8:44 PM
>To: Justen, Jordan L; Thomas Palmer; edk2-devel@lists.01.org
>Subject: Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into RngDxe
>
>Thomas,
>
>Thanks for doing this.
>I think it's better to separate your patch into two parts (one for MdePkg, and
>the other for SecurityPkg). Then you can CC me as Jordan's suggestion.
>
>
>Best Regards & Thanks,
>LONG, Qin
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Jordan Justen
>> Sent: Thursday, October 08, 2015 11:36 AM
>> To: Thomas Palmer; edk2-devel@lists.01.org
>> Subject: Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into
>> RngDxe
>>
>> In the subject line, 'Pkg-Module' should be something like 'MdePkg:'
>> or 'SecurityPkg/RandomNumberGenerator:'.
>>
>> On 2015-10-07 18:55:42, Thomas Palmer wrote:
>> > Use the new RngLib to provide the IA32/X64 random data for RngDxe.
>> > Remove x86 specific functions from RdRand files.
>> > Clean up files in RngDxe/IA32 and RngDxe/X64 that are subsumed by files
>> in BaseRngLib.
>> > Simplify RngDxe by using WriteUnaligned64 for both IA32 and X64
>> platforms.
>> > Create and use GetRandomNumber128 in RngDxe to leverage 128 bit
>> > support found in some HW RNG devices
>>
>> It sounds like you are doing about 5 things here. How about 5 patches?
>>
>> Each patch should only touch one package whenever possiable.
>>
>> Also, consider adding 'Cc:' near your Signed-off-by for the maintainers of a
>> package. (see Maintainers.txt)
>>
>> -Jordan
>>
>> > Contributed-under: TianoCore Contribution Agreement 1.0
>> > Signed-off-by: Thomas Palmer 
>> > ---
>> >  MdePkg/Include/Library/RngLib.h|   17 ++
>> >  MdePkg/Library/BaseRngLib/BaseRng.c|   32 +++
>> >  .../RngDxe/IA32/AsmRdRand.asm  |   67 -
>> >  .../RandomNumberGenerator/RngDxe/IA32/GccRdRand.c  |   69 --
>> >  .../RandomNumberGenerator/RngDxe/IA32/RdRandWord.c |  104 
>> > SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c  |  256
>> > ++--
>> SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.h  |  151 +---
>> >  SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c  |9 +-
>> >  .../RandomNumberGenerator/RngDxe/RngDxe.inf|   14 +-
>> >  .../RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm |   83 ---
>> >  .../RandomNumberGenerator/RngDxe/X64/GccRdRand.c   |   95 
>> >  .../RandomNumberGenerator/RngDxe/X64/RdRandWord.c  |   70 --
>> >  SecurityPkg/SecurityPkg.dsc|3 +
>> >  13 files changed, 75 insertions(+), 895 deletions(-)  delete mode
>> > 100644
>> SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
>> >  delete mode 100644
>> > SecurityPkg/RandomNumberGenerator/RngDxe/IA32/GccRdRand.c
>> >  delete mode 100644
>> > SecurityPkg/RandomNumberGenerator/RngDxe/IA32/RdRandWord.c
>> >  delete mode 100644
>> > SecurityPkg/RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm
>> >  delete mode 100644
>> > SecurityPkg/RandomNumberGenerator/RngDxe/X64/GccRdRand.c
>> >  delete mode 100644
>> > SecurityPkg/RandomNumberGenerator/RngDxe/X64/RdRandWord.c
>> >
>> > diff --git a/MdePkg/Include/Library/RngLib.h
>> > b/MdePkg/Include/Library/RngLib.h index 157a931..ece4394 100644
>> > --- a/MdePkg/Include/Library/RngLib.h
>> > +++ b/MdePkg/Include/Library/RngLib.h
>> > @@ -66,4 +66,21 @@ GetRandomNumber64 (
>> >OUT UINT64*Rand
>> >);
>> >
>> > +/**
>> > +  Generates a 128-bit random number.
>> > +
>> > +  if Rand is NULL, then ASSERT().
>> > +
>> > +  @param[out] Rand Buffer pointer to store the 128-bit random value.
>> > +
>> > +  @retval TRUE Random number generated successfully.
>> > +  @retval FALSEFailed to generate the random number.
>> > +
>> > +**/
>> > +BOOLEAN
>> > +EFIAPI
>> > +GetRandomNumber128 (
>> > +  OUT UINT64*Rand
>> > +  );
>> > +
>> >  #endif  // __RNG_LIB_H__
>> > diff --git a/MdePkg/Library/BaseRngLib/BaseRng.c
>> > b/MdePkg/Library/BaseRngLib/BaseRng.c
>> > index 279df30..2c8df56 100644
>> > --- a/MdePkg/Library/BaseRngLib/BaseRng.c
>> > +++ b/MdePkg/Library/BaseRngLib/BaseRng.c
>> > @@ -155,3 +155,35 @@ GetRandomNumber64 (
>> >
>> >return FALSE;
>> >  }
>> > +
>> > +/**
>> > +  Generates a 128-bit random number.
>> > +
>> > +  if Rand is NULL, then ASSERT().
>> > +
>> > +  @param[out] Rand Buffer pointer to store the 128-bit random value.
>> > +
>> > +  @retval TRUE Random number generated successfully.
>> > +  @retval FALSEFailed to generate the random number.
>> > +
>> > +**/
>> > +BOOLEAN
>> > +EFIAPI
>> > +GetRandomNumber128 (
>> > +  OUT UINT64*Rand
>> > +  )

Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace include

[Kinney, Michael D]

Andrew,

Yes.  The use of the Ex forms of the PCD Protocol/PPI APIs are required when 
modules are built separately.  The Ex forms of the PCD Protocol/PPI APIs are 
used even if the module source does not use the Ex APIs from the PcdLib if the 
PCDs are listed in a DynamicEx section of a DSC file.

The Ex APIs in the PcdLib are only required in the source code if a modules 
uses 2 PCDs from 2 different token spaces that happen to have the same token 
name.  The sources can select the correct PCD with the Ex API.

Best regards,

Mike


>-Original Message-
>From: af...@apple.com [mailto:af...@apple.com]
>Sent: Thursday, October 08, 2015 8:03 AM
>To: Laszlo Ersek
>Cc: Kinney, Michael D; edk2-de...@ml01.01.org
>Subject: Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing
>UefiCpuPkgTokenSpace include
>
>
>> On Oct 8, 2015, at 4:22 AM, Laszlo Ersek <ler...@redhat.com> wrote:
>>
>> On 10/07/15 23:11, Kinney, Michael D wrote:
>>> Laszlo,
>>>
>>> Good question.
>>>
>>> It is a good practice to have the .h file for each GUID.  The .h file 
>>> contains
>the extern for the global variable associated with the GUID along with data
>structures associated with the GUID.
>>>
>>> For PCD token space GUIDs, there is no data structure and the AutoGen.h
>file contains an extern to all token space GUIDs a module references, so the .h
>file for the token space GUID is not required.
>>>
>>> The C name for a Token space GUID (i.e. gUefiCpuPkgTokenSpaceGuid)
>would be required in C code if the PcdLib PcdGetEx8 (),PcdGetEx16
>(),PcdGetEx32 (),PcdGetEx64 (),PcdGetExBool (),or PcdGetExPtr () APIs are
>used.  Most modules/libs do not use the 'Ex' versions of these, so it is very
>rare for a module to use the C name for a Token space GUID.
>>>
>>> I will remove the UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h from
>the patch set.
>>
>> Thank you for explaining me the PcdGetEx__() family of functions at the
>> same time :) I've been wondering about both them, and how one could
>> resolve token name collisions between different token spaces.
>> Apparently, with the Ex family (but it remains unnecessary in practice).
>>
>
>It is only needed for modules that are not compiled together.
>
>Thanks,
>
>Andrew Fish
>
>> Thank you!
>> Laszlo
>>
>>>
>>> Thanks,
>>>
>>> Mike
>>>
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Wednesday, October 07, 2015 10:38 AM
>>> To: Kinney, Michael D; edk2-de...@ml01.01.org
>>> Subject: Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing
>UefiCpuPkgTokenSpace include
>>>
>>> On 10/05/15 01:57, Michael Kinney wrote:
>>>> Add missing include files for the token space GUID for the UefiCpuPkg
>>>> Add path to the token space include file to the UefiCpuPkg DEC file.
>>>
>>> Is this usual? For example, gUefiOvmfPkgTokenSpaceGuid is also not
>>> defined anywhere else than in the DEC file.
>>>
>>> What could a programmer use UEFICPUPKG_TOKEN_SPACE_GUID /
>>> gUefiCpuPkgTokenSpaceGuid for, in C source code?
>>>
>>> ... Only the following packages / header files seem to expose their
>>> respective token space GUIDs in a similar way:
>>>
>>> MdeModulePkg/Include/Guid/MdeModulePkgTokenSpace.h
>>> MdePkg/Include/Guid/MdePkgTokenSpace.h
>>> PcAtChipsetPkg/Include/Guid/PcAtChipsetTokenSpace.h
>>> PerformancePkg/Include/Guid/PerformancePkgTokenSpace.h
>>> SecurityPkg/Include/Guid/SecurityPkgTokenSpace.h
>>> ShellPkg/Include/Guid/ShellPkgTokenSpace.h
>>> Vlv2DeviceRefCodePkg/Include/Guid/Vlv2DeviceRefCodePkgTokenSpace.h
>>>
>>> Thanks!
>>> Laszlo
>>>
>>>>
>>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>>> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
>>>> ---
>>>> UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h | 25
>+
>>>> UefiCpuPkg/UefiCpuPkg.dec  |  1 +
>>>> 2 files changed, 26 insertions(+)
>>>> create mode 100644 UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
>>>>
>>>> diff --git a/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
>b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
>>>> new file mode 100644
>>>> index 000..6c4e671
>>>> --- /dev/null
>>>> +++ b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
>>>> @@ -0,0 +1,25 @@
>>>

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

[Kinney, Michael D]

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 v4 04/19] UefiCpuPkg: CpuDxe: Wait for APs to enter idle loop

[Kinney, Michael D]

Laszlo,

I have updated the commit message and I have updated source to use gBS->Stall() 
to be consistent with the rest of this module.

I will come back to this module in the future and look into using the 
performance counter functions in the TimerLib and CpuPause(), so this module 
can minimize the wait time for all AP sync operations.

Thanks,

Mike

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Monday, October 19, 2015 6:57 AM
>To: Kinney, Michael D; edk2-de...@ml01.01.org
>Cc: Fan, Jeff
>Subject: Re: [PATCH v4 04/19] UefiCpuPkg: CpuDxe: Wait for APs to enter idle
>loop
>
>comments below
>
>On 10/19/15 09:44, Michael Kinney wrote:
>> Address a race condition in first call to StartupAllAPs() with
>> SingleThread set to TRUE in the MP initialization.  If the APs
>> have not entered their idle loop before StartupAllAPs() is called,
>> then some of the APs will be in an unexpected state, and
>> StartupAllAPs() will hang.  This is the hang condition that is
>> only seen when SingleThread parameter is set to TRUE and
>> StartupAllAPs() is called very shortly after mAPsAlreadyInitFinished
>> is set to TRUE that releases the APs to complete their initialization.
>>
>> An internal function has been added to check if all APs are in the
>> sleeping state in their idle loop.  On the first call to
>> StartupAllAPs(), this internal function is used to make sure the
>> APs are in a state that is compatible with StartupAllAPs() being
>> called.
>
>I think these paragraphs date back to the version of the patch where the
>wait was still conditional on the StartupAllAPs() member being called.
>
>... I think the first paragraph is precise enough (because it describes
>symptoms / an actual reproducer), but the second paragraph should
>reflect that the sleeping state is awaited unconditionally.
>
>> The PcdCpuApInitTimeOutInMicroSeconds is used as the maximum wait
>> time for the APs to enter their idle loop.
>
>Makes sense I believe.
>
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
>> Cc: Jeff Fan <jeff@intel.com>
>> Cc: Laszlo Ersek <ler...@redhat.com>
>> ---
>>  UefiCpuPkg/CpuDxe/CpuMp.c | 62
>+--
>>  1 file changed, 60 insertions(+), 2 deletions(-)
>>
>> diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
>> index fbe43f5..7e7736c 100644
>> --- a/UefiCpuPkg/CpuDxe/CpuMp.c
>> +++ b/UefiCpuPkg/CpuDxe/CpuMp.c
>> @@ -313,6 +313,47 @@ CheckAndUpdateAllAPsToIdleState (
>>  }
>>
>>  /**
>> +  Check if all APs are in state CpuStateSleeping.
>> +
>> +  Return TRUE if all APs are in the CpuStateSleeping state.  Do not
>> +  check the state of the BSP or any disabled APs.
>> +
>> +  @retval TRUE   All APs are in CpuStateSleeping state.
>> +  @retval FALSE  One or more APs are not in CpuStateSleeping state.
>> +
>> +**/
>> +BOOLEAN
>> +CheckAllAPsSleeping (
>> +  VOID
>> +  )
>> +{
>> +  UINTN   ProcessorNumber;
>> +  CPU_DATA_BLOCK  *CpuData;
>> +
>> +  for (ProcessorNumber = 0; ProcessorNumber <
>mMpSystemData.NumberOfProcessors; ProcessorNumber++) {
>> +CpuData = [ProcessorNumber];
>> +if (TestCpuStatusFlag (CpuData, PROCESSOR_AS_BSP_BIT)) {
>> +  //
>> +  // Skip BSP
>> +  //
>> +  continue;
>> +}
>> +
>> +if (!TestCpuStatusFlag (CpuData, PROCESSOR_ENABLED_BIT)) {
>> +  //
>> +  // Skip Disabled processors
>> +  //
>> +  continue;
>> +}
>> +
>> +if (GetApState (CpuData) != CpuStateSleeping) {
>> +  return FALSE;
>> +}
>> +  }
>> +  return TRUE;
>> +}
>> +
>> +/**
>>If the timeout expires before all APs returns from Procedure,
>>we should forcibly terminate the executing AP and fill FailedList back
>>by StartupAllAPs().
>> @@ -1650,8 +1691,9 @@ InitializeMpSupport (
>>VOID
>>)
>>  {
>> -  EFI_STATUSStatus;
>> -  MTRR_SETTINGS MtrrSettings;
>> +  EFI_STATUS Status;
>> +  MTRR_SETTINGS  MtrrSettings;
>> +  UINTN  Timeout;
>>
>>gMaxLogicalProcessorNumber = (UINTN) PcdGet32
>(PcdCpuMaxLogicalProcessorNumber);
>>if (gMaxLogicalProcessorNumber < 1) {
>> @@ -1700,9 +1742,25 @@ InitializeMpSupport (
>>   sizeof (CPU_DATA_BLOCK) *
>mMpSystemData.NumberOfProcessors,
>&g

Re: [edk2] [PATCH v4 03/19] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

[Kinney, Michael D]

Laszlo,

Thanks for the feedback.  

1) I have updated the author using --author='Laszlo Ersek <ler...@redhat.com>'
2) I changed the order of the commits so the MP race condition is fixed before 
your patch to sync MTRRs to all APs.

Best regards,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Monday, October 19, 2015 6:43 AM
>To: Kinney, Michael D; edk2-de...@ml01.01.org
>Cc: edk2-devel
>Subject: Re: [edk2] [PATCH v4 03/19] UefiCpuPkg: CpuDxe: broadcast MTRR
>changes to APs
>
>On 10/19/15 09:44, Michael Kinney wrote:
>> From: edk2-devel <edk2-devel-boun...@lists.01.org>
>
>With SVN it won't matter much ultimately, but considering git per se, I
>think in your git tree my authorship was lost somehow. (The
>Signed-off-by below is correct though.) This can be fixed by:
>- rebasing the series
>- selecting "edit" for this patch
>- committing it without any changes, but with different authorship:
>  git commit --amend --author='Laszlo Ersek <ler...@redhat.com>'
>
>Not overly important, but I think it's useful to know about git commit
>--author.
>
>Another (not super-important) comment: in cases like this, a patch
>series usually applies the fix for the dormant bug first (i.e., patch v4
>04/19), and then introduces the change that would expose the bug (i.e.,
>this patch). The idea being, since the bug is known, there should be no
>point in history where the bug is exposed -- it could be triggered by an
>unrelated bisection, for example.
>
>Again, not too important, but it's so great that you've been using git
>for this work that I can't hold back some unsolicited git tips. :)
>
>Thanks!
>Laszlo
>
>>
>> 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").
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
>> Reviewed-by: Jeff Fan <jeff@intel.com>
>> Reviewed-by: Michael Kinney <michael.d.kin...@intel.com>
>> ---
>>  UefiCpuPkg/CpuDxe/CpuDxe.c | 26 ++
>>  UefiCpuPkg/CpuDxe/CpuMp.c  | 34 +-
>>  UefiCpuPkg/CpuDxe/CpuMp.h  | 13 +
>>  3 files changed, 72 insertions(+), 1 deletion(-)
>>
>> 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/Uefi

Re: [edk2] [PATCH v3 01/52] UefiCpuPkg: CpuDxe: Fix ASSERT() when only 1 CPU detected

[Kinney, Michael D]

Bruce,

No.  Different ASSERT().

That looks like a new bug, and it is in the new code I added to force BSP to 
wait for all APs to enter sleeping state before StartupAllAPs() is called.

How did you reproduce this?

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Bruce Cran
>Sent: Tuesday, October 20, 2015 5:21 PM
>To: Laszlo Ersek; edk2-de...@ml01.01.org
>Subject: Re: [edk2] [PATCH v3 01/52] UefiCpuPkg: CpuDxe: Fix ASSERT() when
>only 1 CPU detected
>
>On 10/14/15 4:25 PM, Laszlo Ersek wrote:
>> From: Michael Kinney 
>>
>> When only 1 CPU is detected and the max CPUs is greater than 1,
>> an ASSERT() is generated because the pages associated with the
>> AP stack have already been freed.  Only do this FreePages() call
>> if there is more than 1 CPU detected.
>
>Is the ASSERT() that was being triggered "LockValue == ((UINTN) 2) ||
>LockValue == ((UINTN) 1)" in:
>
>   AcquireSpinLockOrFail
>   GetMpSpinLock
>   TestCpuStatusFlag
>   CheckAllAPsSleeping
>   InitializeMpSupport
>   InitializeCpu
>   ...
>
>Or is this a separate bug?
>
>--
>Bruce
>___
>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 04/52] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

[Kinney, Michael D]

Laszlo,

I agree with many of your points.

If you prefer, I can consolidate the UefiCpuPkg updates including 6 items you 
list below into my UefiCpuPkg series and get that checked in first so you can 
focus on OVMF SMM.

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Friday, October 16, 2015 11:04 PM
>To: Kinney, Michael D; edk2-de...@ml01.01.org
>Subject: Re: [edk2] [PATCH v3 04/52] UefiCpuPkg: CpuDxe: broadcast MTRR
>changes to APs
>
>On 10/16/15 23:17, Kinney, Michael D wrote:
>> Laszlo,
>>
>> Here is a proposed fix on top of your v3 patch services to address a
>> race condition that was introduced by the v3 patch series call to
>> StartupAllAPs() with SingleThread set to TRUE in the MP
>> initialization.  If the APs have not entered their idle loop before
>> StartupAllAPs() is called, then some of the APs will be in an
>> unexpected state, and StartupAllAPs() will hang.  This is the hang
>> condition that is only seen when SingleThread parameter is set to
>> TRUE and StartupAllAPs() is called very shortly after
>> mAPsAlreadyInitFinished is set to TRUE that releases the APs to
>> complete their initialization.
>>
>> I added an internal function that checks to see if all APs are in the
>> sleeping state in the idle loop.  On the first call to
>> StartupAllAPs(), this internal function is used to make sure the APs
>> are in a state that is compatible with StartupAllAPs() being used.  I
>> put this check in the first call to StartupAllAPs(), so we do not
>> take the delay to wait for the APs unconditionally in the MP init
>> code.  Other work can get done while the APs work their way to their
>> idle loop sleeping state.
>>
>> The one item remaining is to have a timeout with an ASSERT() if
>> timeout is triggered in first call to StartupAllAPs() waiting for the
>> APs to enter idle loop.
>>
>> I also reordered some of the actions InitializeMpSupport(), so the MP
>> Services Protocol and call to StartupAllAPs() are done as late as
>> possible to give APs more time to get to idle loop.
>>
>> Please merge this into your patch series.
>
>Many thanks for this!
>
>I have two comments:
>
>
>First, I don't think that it is my patch "UefiCpuPkg: CpuDxe: broadcast
>MTRR changes to APs" that *introduces* the race condition, with the
>early call to StartupAllAps(). I believe that the race condition exists
>in the current code, and my patch only exposes it.
>
>Namely, my patch adds the StartupAllAps() call right before the MP
>services protocol interface is installed. Considering a case where my
>patch is not applied, but another driver registers a protocol notify
>callback for MP services, that callback would be invoked on the stack of
>InstallMultipleProtocolInterfaces(), while some of the APs might not
>have entered their idle loop yet. If the callback in that other driver
>located the protocol instance quickly, and called StartupAllAps() with
>similar arguments (which would be a valid thing to do), the same issue
>could be triggered. So I think the race is already there; the protocol
>interface gets installed too early.
>
>Which leads me to think that the code you add here under
>(!mStartupAllAPsCalled) should be executed unconditionally, right after
>"mAPsAlreadyInitFinished is set to TRUE that releases the APs to
>complete their initialization". We shouldn't install the MP services
>protocol interface until initialization is complete, and allows for any
>kinds of calls through that interface.
>
>
>Second, I think I'll put aside the SMM series for a short period, and
>work on a smaller UefiCpuPkg + OvmfPkg series. I'm thinking about six
>patches:
>
>(1) split out the crux of this patch (without the code rearrangement)
>and state that it fixes the existent (although mostly un-triggered) race
>condition
>
>(2) refine the above by introducing the timeout you mention. I'm thinking
>
>  GetTimeInNanoSecond (GetPerformanceCounter ())
>
>should be a good way to measure the elapsed time; it seems to be a
>pattern used elsewhere in the tree. This will also require a new PCD.
>What default would you suggest for the timeout?
>
>(3) add the rearrangement that gives more time to the APs to enter their
>idle loops
>
>(4) Include my MTRR broadcast patch
>
>(5) Separately, implement your other suggestion with
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds, from
><http://thread.gmane.org/gmane.comp.bios.edk2.devel/2415/focus=141501>.
>
>(6) Xiao Guangrong provided us with the info for wording a commit for
>OvmfPkg where the

Re: [edk2] [PATCH] Pkg-Module: Integrate new RngLib into RngDxe

[Kinney, Michael D]

Thomas,

In other EDK II functions, we use the name "Uintn" instead of "Word" for a 
function that returns a value that is the natural size of the executing CPU.

Also, I do not think you need the internal work function to generate a natural 
sized random number.

Both IA32 and X64 versions the BaseLib support the AsmRdRand64() function.  
Your implementation can always do work 64-bits at a time using just 
AsmRdRand64().

Mike


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Thomas 
Palmer
Sent: Tuesday, October 06, 2015 9:38 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH] Pkg-Module: Integrate new RngLib into RngDxe

Use the new RngLib to provide the IA32/X64 random data for RngDxe.
Remove x86 specific functions from RdRand files.
Clean up files in RngDxe/IA32 and RngDxe/X64 that are subsumed by files in 
BaseRngLib.
A key piece to this change was creating a RdRandWord and RdRandGetWords 
functions that could work for both IA32 and X64 builds.  The RngLib provides 
functions to get 16,32, and 64 bit random values, but RngDxe uses RdRandWord to 
get a UINTN value.   I use sizeof (UINTN) to determine when to use 
GetRandomNumber32 or GetRandomNumber64

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
---
 .../RngDxe/IA32/AsmRdRand.asm  |   67 
 .../RandomNumberGenerator/RngDxe/IA32/GccRdRand.c  |   69 
 SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c  |  173 +---
 SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.h  |  115 +
 SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c  |9 +-
 .../RandomNumberGenerator/RngDxe/RngDxe.inf|   14 +-
 .../RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm |   83 --
 .../RandomNumberGenerator/RngDxe/X64/GccRdRand.c   |   95 ---
 SecurityPkg/SecurityPkg.dsc|3 +
 9 files changed, 47 insertions(+), 581 deletions(-)
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/GccRdRand.c
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/GccRdRand.c

diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm 
b/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
deleted file mode 100644
index 37b3830..000
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
+++ /dev/null
@@ -1,67 +0,0 @@
-;--
-;
-; Copyright (c) 2013, 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.
-;
-; Module Name:
-;
-;   AsmRdRand.Asm
-;
-; Abstract:
-;
-;   Implementation for 16-, and 32- invocations of RDRAND instruction under 
32bit platform.
-;
-; Notes:
-;
-;   Visual Studio coding practices do not use inline asm since multiple 
compilers and 
-;   architectures are supported assembler not recognizing rdrand instruction 
so using DB's.
-;
-;--
-
-.586P
-.model flat, C
-.code
- 
-;--
-;  Generate a 16 bit random number
-;  Return TRUE if Rand generated successfully, or FALSE if not
-;
-;  BOOLEAN EFIAPI RdRand16Step (UINT16 *Rand);   ECX
-;--
-RdRand16Step  PROC
-; rdrand   ax  ; generate a 16 bit RN into ax, CF=1 if RN 
generated ok, otherwise CF=0
-db 0fh, 0c7h, 0f0h ; rdrand r16:  "0f c7 /6  ModRM:r/m(w)"
-jb rn16_ok ; jmp if CF=1
-xoreax, eax; reg=0 if CF=0
-ret; return with failure status
-rn16_ok:
-mov[ecx], ax
-moveax, 1
-ret
-RdRand16Step ENDP
-
-;--
-;  Generate a 32 bit random number
-;Return TRUE if Rand generated successfully, or FALSE if not
-;
-;  BOOLEAN EFIAPI RdRand32Step (UINT32 *Rand);   ECX
-;--
-RdRand32Step  PROC
-; rdrand   eax ; generate a 32 bit RN into eax, CF=1 if RN 
generated ok, otherwise CF=0
-db 0fh, 0c7h, 0f0h ; rdrand r32:  "0f c7 /6  ModRM:r/m(w)"
-jb rn32_ok

Re: [edk2] [PATCH] Pkg-Module: Integrate new RngLib into RngDxe v2

[Kinney, Michael D]

Thomas,

How about something like below to further simplify to one function and handle 
alignment issues.

Also, do you know where the 10us delay comes from in RdRandGetSeed128()?  Is 
there a pointer to a document?  

EFI_STATUS
EFIAPI
RdRandGetBytes (
  IN UINTN Length,
  OUT UINT8*RandBuffer
  )
{
  BOOLEAN  IsRandom;
  UINT64   TempRand;
  
  while (Length > 0) {
IsRandom = GetRandomNumber64 ();
if (!IsRandom) {
  return EFI_NOT_READY;
}
if (Length >= sizeof (UINT64)) {
  WriteUnaligned64 (RandBuffer, TempRand);
  Length -= sizeof (UINT64);
} else {
  CopyMem (RandBuffer, , Length);
  Length = 0;
}
  }
  return EFI_SUCCESS;
}

Thanks,

Mike

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Thomas 
Palmer
Sent: Tuesday, October 06, 2015 1:40 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH] Pkg-Module: Integrate new RngLib into RngDxe v2

Use the new RngLib to provide the IA32/X64 random data for RngDxe.
Remove x86 specific functions from RdRand files.
Clean up files in RngDxe/IA32 and RngDxe/X64 that are subsumed by files in 
BaseRngLib.
Simplify RngDxe by using GetRandomNumber64 for both IA32 and X64 platforms. 
Explicitly use UINT64 instead of UINTN where appropriate

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
---
 .../RngDxe/IA32/AsmRdRand.asm  |   67 --
 .../RandomNumberGenerator/RngDxe/IA32/GccRdRand.c  |   69 --
 .../RandomNumberGenerator/RngDxe/IA32/RdRandWord.c |  104 -
 SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c  |  241 +---
 SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.h  |  151 +---
 SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c  |9 +-
 .../RandomNumberGenerator/RngDxe/RngDxe.inf|   14 +-
 .../RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm |   83 ---
 .../RandomNumberGenerator/RngDxe/X64/GccRdRand.c   |   95 
 .../RandomNumberGenerator/RngDxe/X64/RdRandWord.c  |   70 --
 SecurityPkg/SecurityPkg.dsc|3 +
 11 files changed, 60 insertions(+), 846 deletions(-)
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/GccRdRand.c
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/RdRandWord.c
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/GccRdRand.c
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/RdRandWord.c

diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm 
b/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
deleted file mode 100644
index 37b3830..000
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
+++ /dev/null
@@ -1,67 +0,0 @@
-;--
-;
-; Copyright (c) 2013, 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.
-;
-; Module Name:
-;
-;   AsmRdRand.Asm
-;
-; Abstract:
-;
-;   Implementation for 16-, and 32- invocations of RDRAND instruction under 
32bit platform.
-;
-; Notes:
-;
-;   Visual Studio coding practices do not use inline asm since multiple 
compilers and 
-;   architectures are supported assembler not recognizing rdrand instruction 
so using DB's.
-;
-;--
-
-.586P
-.model flat, C
-.code
- 
-;--
-;  Generate a 16 bit random number
-;  Return TRUE if Rand generated successfully, or FALSE if not
-;
-;  BOOLEAN EFIAPI RdRand16Step (UINT16 *Rand);   ECX
-;--
-RdRand16Step  PROC
-; rdrand   ax  ; generate a 16 bit RN into ax, CF=1 if RN 
generated ok, otherwise CF=0
-db 0fh, 0c7h, 0f0h ; rdrand r16:  "0f c7 /6  ModRM:r/m(w)"
-jb rn16_ok ; jmp if CF=1
-xoreax, eax; reg=0 if CF=0
-ret; return with failure status
-rn16_ok:
-mov[ecx], ax
-moveax, 1
-ret
-RdRand16Step ENDP
-
-;--
-;  Generate a 32 bit random number
-;Return TRUE if Rand generated successfully, or FALSE if not
-;
-;  BOOLEAN 

Re: [edk2] [PATCH 0/7] UefiCpuPkg: Add CPU SMM and SecCore

[Kinney, Michael D]

Hi Laszlo,

I am looking at the files on my local system from that github branch, and 
spot checking a few new files, they all have CRLF at the end of each line.

Can you give an example file where you are seeing this issue?

Do I maybe have an incorrect git configuration?

Thanks,

Mike

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Tuesday, October 13, 2015 11:42 AM
>To: Kinney, Michael D; edk2-de...@ml01.01.org
>Subject: Re: [edk2] [PATCH 0/7] UefiCpuPkg: Add CPU SMM and SecCore
>
>Mike,
>
>On 10/05/15 01:57, Michael Kinney wrote:
>> This series adds IA32 and X64 support for SMM and SEC to the
>> UefiCpuPkg.  The SMM CPU modules and libraries work with the
>> SMM IPL and SMM Core from the MdeModulePkg to initialize the SMM
>> environment and provide the services required for a DXE_SMM_DRIVER
>> to register SMI handlers that execute from SMRAM in SMM mode.
>>
>> Public branch: https://github.com/mdkinney/edk2/tree/AddSmmUefiCpuPkg
>
>I just realized that the new source files added by the above branch
>don't have CRLF line terminators -- they have LF only.
>
>However, since the patches don't overlap on the new files, it is not
>hard to run "git rebase -i" on the branch, stop for editing after each
>patch, and run "unix2dos" on the new files, before continuing the
>rebase. Because no new file is touched by another patch, there won't be
>any conflicts.
>
>Thanks
>Laszlo
>
>> Michael Kinney (7):
>>   UefiCpuPkg: Add Cpuid.h for CPUID related defines
>>   UefiCpuPkg: Update CPU MP drivers for PiSmmCpuDxeSmm
>>   UefiCpuPkg: Add SMM Communication PPI and Handler Modules
>>   UefiCpuPkg: Add SecCore module
>>   UefiCpuPkg: Add PiSmmCpuDxeSmm module include files
>>   UefiCpiPkg: Add PiSmmCpuDxeSmm module
>>   UefiCpuPkg: Add missing UefiCpuPkgTokenSpace GUID
>>
>>  UefiCpuPkg/CpuDxe/CpuMp.c  |   47 +-
>>  UefiCpuPkg/CpuMpPei/CpuMpPei.c |   34 +-
>>  UefiCpuPkg/CpuMpPei/CpuMpPei.h |1 +
>>  UefiCpuPkg/Include/AcpiCpuData.h   |   72 +
>>  UefiCpuPkg/Include/CpuHotPlugData.h|   33 +
>>  UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h |   25 +
>>  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 -> 1646 bytes
>>  .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c  |  559 
>>  .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf|   39 +
>>  .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.uni|  Bin 0 -> 1674 bytes
>>  .../SmmCpuPlatformHookLibNull.c|  108 ++
>>  .../SmmCpuPlatformHookLibNull.inf  |   40 +
>>  .../SmmCpuPlatformHookLibNull.uni  |  Bin 0 -> 1606 bytes
>>  .../PiSmmCommunication/PiSmmCommunicationPei.c |  425 ++
>>  .../PiSmmCommunication/PiSmmCommunicationPei.inf   |   70 +
>>  .../PiSmmCommunication/PiSmmCommunicationPei.uni   |  Bin 0 -> 2066
>bytes
>>  .../PiSmmCommunicationPeiExtra.uni |  Bin 0 -> 1374 bytes
>>  .../PiSmmCommunication/PiSmmCommunicationPrivate.h |   30 +
>>  .../PiSmmCommunication/PiSmmCommunicationSmm.c |  269 
>>  .../PiSmmCommunication/PiSmmCommunicationSmm.inf   |   82 ++
>>  .../PiSmmCommunication/PiSmmCommunicationSmm.uni   |  Bin 0 -> 3004
>bytes
>>  .../PiSmmCommunicationSmmExtra.uni |  Bin 0 -> 1396 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 |   45 +
>>  Uefi

Re: [edk2] [PATCH 2/3] OvmfPkg: Fix VS20xx and DebugAgent ASSERT()

[Kinney, Michael D]

Laszlo and Jordan,

I agree.  Thanks for the feedback.

The SOURCE_DEBUG_ENABLE issue is a completely separate issue and

I will regenerate a patch for that issue that is not related to SMM work.

It only got into the mix of changes because I was using SOURCE_DEBUG_ENABLE to 
debug some SMM issues. 

Mike

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Tuesday, October 13, 2015 11:56 AM
>To: Justen, Jordan L; Kinney, Michael D; edk2-de...@ml01.01.org
>Subject: Re: [edk2] [PATCH 2/3] OvmfPkg: Fix VS20xx and DebugAgent ASSERT()
>
>On 10/13/15 20:47, Jordan Justen wrote:
>> On 2015-10-13 10:49:23, Michael Kinney wrote:
>>> Fix build breaks when building with VS20xx.  The
>>> loop that fills the BaseExtractGuidedSectionLib
>>> handler table with zeros must use a volatile variable
>>> to prevent the optimizing compiler from adding a call
>>> to a compiler intrinsic.
>>>
>>> Also, update initialization of SEC phase to initialze
>>> the state of the Local APIC Timer hardware before the
>>> DebugAgentLib is initialized that depends on the Local
>>> APIC Timer hardware being in an initialized state.
>>> An ASSERT() was recently added to Local APIC libs
>>> to verifiy that the Local APIC is initialized before
>>> use and if SOURCE_DEBUG_ENABLE is set, this ASSERT()
>>> was being triggered.
>>
>> Sounds like 2 separate changes.
>
>I agree. What's more, the APIC change seems orthogonal to the SMM work,
>hence I think either the blurb (= 0/3) subject should be changed (from
>"SMM patch issues"), or the LAPIC timer init should not only be in a
>separate patch, but even in a separate posting (i.e., outside of this
>series).
>
>>
>> Actually, for the 'Table' issue, I think you should just reply to
>> Laszlo's "OvmfPkg: Sec: force reinit of BaseExtractGuidedSectionLib
>> handler table" and ask him to use ZeroMem instead of the loop.
>
>There's a comment about that in the code. The zeroing happens (must
>happen) before any library constructors are invoked. Therefore no
>library functions can be called.
>
>Thanks!
>Laszlo
>
>>
>> -Jordan
>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
>>> ---
>>>  OvmfPkg/Sec/SecMain.c   | 11 ---
>>>  OvmfPkg/Sec/SecMain.inf |  3 ++-
>>>  2 files changed, 10 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
>>> index 26a54d0..5ad62a5 100644
>>> --- a/OvmfPkg/Sec/SecMain.c
>>> +++ b/OvmfPkg/Sec/SecMain.c
>>> @@ -1,7 +1,7 @@
>>>  /** @file
>>>Main SEC phase code.  Transitions to PEI.
>>>
>>> -  Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.
>>> +  Copyright (c) 2008 - 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
>>> @@ -28,6 +28,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  #include 
>>>
>>> @@ -717,6 +718,7 @@ SecCoreStartupWithStack (
>>>SEC_IDT_TABLE   IdtTableInStack;
>>>IA32_DESCRIPTOR IdtDescriptor;
>>>UINT32  Index;
>>> +  volatile UINT8  *Table;
>>>
>>>//
>>>// This code may be running on the S3 resume boot path, where RAM
>has been
>>> @@ -731,8 +733,6 @@ SecCoreStartupWithStack (
>>>// invocations are preprocessed to constants.)
>>>//
>>>if (FeaturePcdGet (PcdSmmSmramRequire)) {
>>> -UINT8 *Table;
>>> -
>>>  Table = (UINT8*)(UINTN)FixedPcdGet64
>(PcdGuidedExtractHandlerTableAddress);
>>>
>>>  for (Index = 0;
>>>   Index < FixedPcdGet32 (PcdGuidedExtractHandlerTableSize);
>>> @@ -815,6 +815,11 @@ SecCoreStartupWithStack (
>>>//
>>>IoWrite8 (0x21, 0xff);
>>>IoWrite8 (0xA1, 0xff);
>>> +
>>> +  //
>>> +  // Initialize Local APIC Timer hardware before initializing the Debug
>Agent and the debug timer is enabled
>>> +  //
>>> +  InitializeApicTimer (0, MAX_UINT32, TRUE, 5);
>>>
>>>//
>>>// Initialize Debug Agent to support source level debug in

Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

[Kinney, Michael D]

Laszlo,

Thanks for the feedback.  I agree I need to update UefiCpuPkg DSC file.

Mike

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Friday, October 09, 2015 6:57 AM
>To: Kinney, Michael D
>Cc: edk2-de...@ml01.01.org
>Subject: Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module
>
>Mike,
>
>On 10/05/15 01:57, Michael Kinney wrote:
>> Add module that initializes a CPU for the SMM envirnment and
>> installs the first level SMI handler.  This module along with the
>> SMM IPL and SMM Core provide the services required for
>> DXE_SMM_DRIVERS to register hardware and software SMI handlers.
>>
>> CPU specific features are abstracted through the SmmCpuFeaturesLib
>>
>> Platform specific features are abstracted through the
>> SmmCpuPlatformHookLib
>>
>> Several PCDs are added to enable/disable features and configure
>> settings for the PiSmmCpuDxeSmm module
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
>> ---
>
>I found that this version of PiSmmCpuDxeSmm depends on
>CpuExceptionHandlerLib (Quark's doesn't).
>
>The following interfaces from the library class are called:
>- InitializeCpuExceptionHandlers()
>- RegisterCpuInterruptHandler()
>
>I think this makes sense. The call sites are:
>
>  PiCpuSmmEntry
>InitializeSmmIdt
>  InitializeCpuExceptionHandlers
>
>  SmmRestoreCpu
>InitializeCpuExceptionHandlers
>
>  SmmRegisterExceptionHandler ==
>mSmmCpuService.RegisterExceptionHandler
>RegisterCpuInterruptHandler
>
>What I don't understand though is why the CpuExceptionHandlerLib class
>is resolved to a NULL instance, in "UefiCpuPkg/UefiCpuPkg.dsc":
>
>
>CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNul
>l/CpuExceptionHandlerLibNull.inf
>
>OVMF uses the following non-null instances (for the appropriate module
>types):
>
>-
>UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.i
>nf
>-
>UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
>
>and as far as I remember, these exception handler library instances
>print, by default, those fault information dumps (to the serial port)
>that are very helpful for debugging incorrect pointer references and the
>like.
>
>So why doesn't this module use the corresponding SMM driver instance:
>
>-
>UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.in
>f
>
>and why does it use a NULL instance instead?

Good point.  The DSC file in the UefiCpuPkg is there to test the build of the
Modules/libraries, so the specific lib instance from another package is not
critical.  I agree it makes sense to put in the preferred lib mappings is 
possible
So I will update the DSC file for UefiCpuPkg to use the correct 
CpuExceptionHandlerLib for each module type.

>
>I realize that this module has its own fault info dumping facility
>(called SmiPFHandler(), specific to Ia32 vs. X64), similarly to the
>version in Quark. That handler calls DumpModuleInfoByIp(), which should
>do what I like to have -- helpful location info.
>
>However, SmiPFHandler() is registered with SmmRegisterExceptionHandler()
>-- since PcdCpuSmmProfileEnable defaults to FALSE --, and that call
>ultimately ends up in CpuExceptionHandlerLib. See the third call tree
>excerpt at the top -- in total, we have:
>
>SmmInitPageTable()
>  SmmRegisterExceptionHandler(SmiPFHandler)
>RegisterCpuInterruptHandler(SmiPFHandler)
>  // implemented by CpuExceptionHandlerLib
>
>Now, given that the CpuExceptionHandlerLib instance is the Null one here
>(according to UefiCpuPkg/UefiCpuPkg.dsc), this PF handler will actually
>*not* be installed. Is that your intent?
>
>I don't think so. Your patch doesn't seem to affect the
>CpuExceptionHandlerLib resolutions in any way; therefore I believe this
>is an omission in the patch.
>
>And, I think it doesn't only affect PiSmmCpuDxeSmm, but also SecCore
>(which you added in patch 4/7 of this series).
>
>On the other hand... I can see a preexistent client of
>CpuExceptionHandlerLib in UefiCpuPkg: CpuDxe. (Of type DXE_DRIVER.)
>Since the default Null resolution affects that module too, I'm now
>inclined to think that maybe this is all intentional *within* UefiCpuPkg.
>
>Either way, I'll go ahead and resolve CpuExceptionHandlerLib to
>SmmCpuExceptionHandlerLib, for DXE_SMM_DRIVER modules, in OVMF. That
>should be consistent with the current resolutions we have for other (SEC
>/ PEIM / DXE_DRIVER / ...) modules already.

Yes.  A platform specific DSC must use the right lib mapping based on
module type.  

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

Re: [edk2] [Patch 2/2] UefiCpuPkg/SmmFeatureLib: Check SmmFeatureControl by Code_Access_Chk

[Kinney, Michael D]

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

Mike

-Original Message-
From: Fan, Jeff 
Sent: Tuesday, November 17, 2015 10:45 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Yao, Jiewen 
<jiewen@intel.com>
Subject: [Patch 2/2] UefiCpuPkg/SmmFeatureLib: Check SmmFeatureControl by 
Code_Access_Chk

Bit SMM_Code_Access_Chk (SMM-RO) in MSR_SMM_MCA_CAP is defined in SDM.
If set to 1 indicates that the SMM code access restriction is supported and the 
MSR_SMM_FEATURE_CONTROL is supported.

If this bit is not set, we needn't to access register SmmFetureControl.
Otherwise, #GP exception may happen.
We need to check if SmmFeatureControl support or not by checking 
SMM_Code_Access_Chk (SMM-RO) in MSR_SMM_MCA_CAP.

Because MSR_SMM_MCA_CAP is SMM-RO register, we should move this check from 
SmmCpuFeaturesLibConstructor (non-SMM) to SmmCpuFeaturesInitializeProcessor 
(SMM).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff@intel.com>
CC: Michael Kinney <michael.d.kin...@intel.com>
CC: Jiewen Yao <jiewen@intel.com>
---
 .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c  | 54 --
 1 file changed, 40 insertions(+), 14 deletions(-)

diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index 0c1610d..b839d31 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -36,6 +36,12 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define  SMM_FEATURES_LIB_SMM_FEATURE_CONTROL  0x4E0
 
 //
+// MSRs required for configuration of SMM Code Access Check //
+#define SMM_FEATURES_LIB_IA32_MCA_CAP  0x17D
+#define   SMM_CODE_ACCESS_CHK_BIT  BIT58
+
+//
 // Set default value to assume SMRR is not supported  //  BOOLEAN  
mSmrrSupported = FALSE; @@ -133,20 +139,6 @@ SmmCpuFeaturesLibConstructor (
 
   //
   // Intel(R) 64 and IA-32 Architectures Software Developer's Manual
-  // Volume 3C, Section 35.10.1 MSRs in 4th Generation Intel(R) Core(TM)
-  // Processor Family
-  //
-  // If CPU Family/Model is 06_3C, 06_45, or 06_46 then use 4th Generation
-  // Intel(R) Core(TM) Processor Family MSRs
-  //
-  if (FamilyId == 0x06) {
-if (ModelId == 0x3C || ModelId == 0x45 || ModelId == 0x46) {
-  mSmmFeatureControlSupported = TRUE;
-}
-  }
-
-  //
-  // Intel(R) 64 and IA-32 Architectures Software Developer's Manual
   // Volume 3C, Section 34.4.2 SMRAM Caching
   //   An IA-32 processor does not automatically write back and invalidate its
   //   caches before entering SMM or before exiting SMM. Because of this 
behavior,
@@ -214,6 +206,10 @@ SmmCpuFeaturesInitializeProcessor (  {
   SMRAM_SAVE_STATE_MAP  *CpuState;
   UINT64FeatureControl;
+  UINT32RegEax;
+  UINT32RegEdx;
+  UINTN FamilyId;
+  UINTN ModelId;
 
   //
   // Configure SMBASE.
@@ -253,6 +249,36 @@ SmmCpuFeaturesInitializeProcessor (
 AsmWriteMsr64 (mSmrrPhysMaskMsr, (~(CpuHotPlugData->SmrrSize - 1) & 
EFI_MSR_SMRR_MASK));
 mSmrrEnabled[CpuIndex] = FALSE;
   }
+
+  //
+  // Retrieve CPU Family and Model
+  //
+  AsmCpuid (CPUID_VERSION_INFO, , NULL, NULL, );  
+ FamilyId = (RegEax >> 8) & 0xf;  ModelId  = (RegEax >> 4) & 0xf;  if 
+ (FamilyId == 0x06 || FamilyId == 0x0f) {
+ModelId = ModelId | ((RegEax >> 12) & 0xf0);  }
+
+  //
+  // Intel(R) 64 and IA-32 Architectures Software Developer's Manual  
+ // Volume 3C, Section 35.10.1 MSRs in 4th Generation Intel(R) Core(TM)  
+ // Processor Family.
+  //
+  // If CPU Family/Model is 06_3C, 06_45, or 06_46 then use 4th 
+ Generation  // Intel(R) Core(TM) Processor Family MSRs.
+  //
+  if (FamilyId == 0x06) {
+if (ModelId == 0x3C || ModelId == 0x45 || ModelId == 0x46) {
+  //
+  // Check to see if the CPU supports the SMM Code Access Check feature
+  // Do not access this MSR unless the CPU supports the 
SmmRegFeatureControl
+  //
+  if ((AsmReadMsr64 (SMM_FEATURES_LIB_IA32_MCA_CAP) & 
SMM_CODE_ACCESS_CHK_BIT) != 0) {
+mSmmFeatureControlSupported = TRUE;
+  }
+}
+  }
 }
 
 /**
--
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 V2 03/12] MdeModulePkg BaseSerialPortLib16550: Add GetControl/SetControl/SetAttributes implementation

[Kinney, Michael D]

Star,

There are a few comments included below for the SerialPortSetAttributes() 
function header comment block.  

With those comment block fixes: 

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

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star 
> Zeng
> Sent: Tuesday, November 17, 2015 3:07 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Tian, Feng 
> <feng.t...@intel.com>; Gao, Liming <liming@intel.com>
> Subject: [edk2] [PATCH V2 03/12] MdeModulePkg BaseSerialPortLib16550: Add 
> GetControl/SetControl/SetAttributes implementation
> 
> Cc: Michael D Kinney <michael.d.kin...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng <star.z...@intel.com>
> ---
>  .../BaseSerialPortLib16550.c   | 341 
> +
>  1 file changed, 341 insertions(+)
> 
> diff --git 
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
> index 3209115..03c9960 100644
> --- a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
> +++ b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550
> +++ .c
> @@ -40,7 +40,9 @@
>  #define R_UART_LCR3
>  #define   B_UART_LCR_DLAB BIT7
>  #define R_UART_MCR4
> +#define   B_UART_MCR_DTRC BIT0
>  #define   B_UART_MCR_RTS  BIT1
> +#define   B_UART_MCR_LME  BIT4
>  #define R_UART_LSR5
>  #define   B_UART_LSR_RXRDYBIT0
>  #define   B_UART_LSR_TXRDYBIT5
> @@ -48,6 +50,8 @@
>  #define R_UART_MSR6
>  #define   B_UART_MSR_CTS  BIT4
>  #define   B_UART_MSR_DSR  BIT5
> +#define   B_UART_MSR_RI   BIT6
> +#define   B_UART_MSR_DCD  BIT7
> 
>  //
>  // 4-byte structure for each PCI node in PcdSerialPciDeviceInfo @@ -761,3 
> +765,340 @@ SerialPortPoll (
> 
>return FALSE;
>  }
> +
> +/**
> +  Sets the control bits on a serial device.
> +
> +  @param ControlSets the bits of Control that are settable.
> +
> +  @retval RETURN_SUCCESSThe new control bits were set on the serial 
> device.
> +  @retval RETURN_UNSUPPORTEDThe serial device does not support this 
> operation.
> +  @retval RETURN_DEVICE_ERROR   The serial device is not functioning 
> correctly.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +SerialPortSetControl (
> +  IN UINT32 Control
> +  )
> +{
> +  UINTN SerialRegisterBase;
> +  UINT8 Mcr;
> +
> +  //
> +  // First determine the parameter is invalid.
> +  //
> +  if ((Control & (~(EFI_SERIAL_REQUEST_TO_SEND | 
> EFI_SERIAL_DATA_TERMINAL_READY |
> +EFI_SERIAL_HARDWARE_LOOPBACK_ENABLE | 
> EFI_SERIAL_SOFTWARE_LOOPBACK_ENABLE |
> +EFI_SERIAL_HARDWARE_FLOW_CONTROL_ENABLE))) != 0) {
> +return RETURN_UNSUPPORTED;
> +  }
> +
> +  SerialRegisterBase = GetSerialRegisterBase ();  if
> + (SerialRegisterBase ==0) {
> +return RETURN_UNSUPPORTED;
> +  }
> +
> +  //
> +  // Read the Modem Control Register.
> +  //
> +  Mcr = SerialPortReadRegister (SerialRegisterBase, R_UART_MCR);  Mcr
> + &= (~(B_UART_MCR_DTRC | B_UART_MCR_RTS | B_UART_MCR_LME));
> +
> +  if ((Control & EFI_SERIAL_DATA_TERMINAL_READY) == 
> EFI_SERIAL_DATA_TERMINAL_READY) {
> +Mcr |= B_UART_MCR_DTRC;
> +  }
> +
> +  if ((Control & EFI_SERIAL_REQUEST_TO_SEND) == EFI_SERIAL_REQUEST_TO_SEND) {
> +Mcr |= B_UART_MCR_RTS;
> +  }
> +
> +  if ((Control & EFI_SERIAL_HARDWARE_LOOPBACK_ENABLE) == 
> EFI_SERIAL_HARDWARE_LOOPBACK_ENABLE) {
> +Mcr |= B_UART_MCR_LME;
> +  }
> +
> +  //
> +  // Write the Modem Control Register.
> +  //
> +  SerialPortWriteRegister (SerialRegisterBase, R_UART_MCR, Mcr);
> +
> +  return RETURN_SUCCESS;
> +}
> +
> +/**
> +  Retrieve the status of the control bits on a serial device.
> +
> +  @param ControlA pointer to return the current control 
> signals from the serial device.
> +
> +  @retval RETURN_SUCCESSThe control bits were read from the serial 
> device.
> +  @retval RETURN_UNSUPPORTEDThe serial device does not support this 
> operation.
> +  @retval RETURN_DEVICE_ERROR   The serial device is not functioning 
> correctly.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +SerialPortGetControl (
> +  OUT UINT32 *Control
> +  )
> +{
> +  UINTN SerialRe

Re: [edk2] [Patch 1/2] UefiCpuPkg: Not touch SmmFeatureControl if Code_Access_Chk not Set

[Kinney, Michael D]

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

Mike
-Original Message-
From: Fan, Jeff 
Sent: Tuesday, November 17, 2015 10:45 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Yao, Jiewen 
<jiewen@intel.com>
Subject: [Patch 1/2] UefiCpuPkg: Not touch SmmFeatureControl if Code_Access_Chk 
not Set

Bit SMM_Code_Access_Chk (SMM-RO) in MSR_SMM_MCA_CAP is defined in SDM.
If set to 1 indicates that the SMM code access restriction is supported and the 
MSR_SMM_FEATURE_CONTROL is supported.

If this bit is not set, we needn't to access register SmmFetureControl.
Otherwise, #GP exception may happen.

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

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
index de681c0..532ac09 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -1309,9 +1309,9 @@ ConfigSmmCodeAccessCheckOnCurrentProcessor (
   NewSmmFeatureControlMsr = SmmFeatureControlMsr;
   if (mSmmCodeAccessCheckEnable) {
 NewSmmFeatureControlMsr |= SMM_CODE_CHK_EN_BIT;
-  }
-  if (FeaturePcdGet (PcdCpuSmmFeatureControlMsrLock)) {
-NewSmmFeatureControlMsr |= SMM_FEATURE_CONTROL_LOCK_BIT;
+if (FeaturePcdGet (PcdCpuSmmFeatureControlMsrLock)) {
+  NewSmmFeatureControlMsr |= SMM_FEATURE_CONTROL_LOCK_BIT;
+}
   }
 
   //
@@ -1354,13 +1354,6 @@ ConfigSmmCodeAccessCheck (
   //
   if ((AsmReadMsr64 (EFI_MSR_SMM_MCA_CAP) & SMM_CODE_ACCESS_CHK_BIT) == 0) {
 mSmmCodeAccessCheckEnable = FALSE;
-  }
-
-  //
-  // If the SMM Code Access Check feature is disabled and the Feature Control 
MSR
-  // is not being locked, then no additional work is required
-  //
-  if (!mSmmCodeAccessCheckEnable && !FeaturePcdGet 
(PcdCpuSmmFeatureControlMsrLock)) {
 return;
   }
 
--
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 V2 01/12] MdePkg SerialPortLib: Upstream GetControl/SetControl/SetAttributes interfaces

[Kinney, Michael D]

Star,

There are a few comments included below for the SerialPortSetAttributes() 
function header comment block.  

With those comment block fixes: 

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

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star 
> Zeng
> Sent: Tuesday, November 17, 2015 3:07 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming 
> <liming@intel.com>
> Subject: [edk2] [PATCH V2 01/12] MdePkg SerialPortLib: Upstream 
> GetControl/SetControl/SetAttributes interfaces
> 
> The extended interfaces GetControl/SetControl/SetAttributes are from 
> EmbeddedPkg/Include/Library/SerialPortExtLib.h.
> 
> Cc: Michael D Kinney <michael.d.kin...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng <star.z...@intel.com>
> ---
>  MdePkg/Include/Library/SerialPortLib.h | 76 +++-
>  .../BaseSerialPortLibNull/BaseSerialPortLibNull.c  | 81 
> +-
>  2 files changed, 155 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Library/SerialPortLib.h 
> b/MdePkg/Include/Library/SerialPortLib.h
> index 8f95786..28a3a23 100644
> --- a/MdePkg/Include/Library/SerialPortLib.h
> +++ b/MdePkg/Include/Library/SerialPortLib.h
> @@ -1,7 +1,8 @@
>  /** @file
>This library class provides common serial I/O port functions.
> 
> -Copyright (c) 2006 - 2008, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2012 - 2014, ARM Ltd. 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 +16,9 @@ WITHOUT WARRANTIES OR
> REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>  #ifndef __SERIAL_PORT_LIB__
>  #define __SERIAL_PORT_LIB__
> 
> +#include 
> +#include 
> +
>  /**
>Initialize the serial device hardware.
> 
> @@ -97,4 +101,74 @@ SerialPortPoll (
>VOID
>);
> 
> +/**
> +  Sets the control bits on a serial device.
> +
> +  @param ControlSets the bits of Control that are settable.
> +
> +  @retval RETURN_SUCCESSThe new control bits were set on the serial 
> device.
> +  @retval RETURN_UNSUPPORTEDThe serial device does not support this 
> operation.
> +  @retval RETURN_DEVICE_ERROR   The serial device is not functioning 
> correctly.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +SerialPortSetControl (
> +  IN UINT32 Control
> +  );
> +
> +/**
> +  Retrieve the status of the control bits on a serial device.
> +
> +  @param ControlA pointer to return the current control 
> signals from the serial device.
> +
> +  @retval RETURN_SUCCESSThe control bits were read from the serial 
> device.
> +  @retval RETURN_UNSUPPORTEDThe serial device does not support this 
> operation.
> +  @retval RETURN_DEVICE_ERROR   The serial device is not functioning 
> correctly.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +SerialPortGetControl (
> +  OUT UINT32 *Control
> +  );
> +
> +/**
> +  Sets the baud rate, receive FIFO depth, transmit/receice time out,
> +parity,
> +  data buts, and stop bits on a serial device.
> +
> +  @param BaudRate   The requested baud rate. A BaudRate value of 0 
> will use the
> +device's default interface speed.
> +  @param ReveiveFifoDepth   The requested depth of the FIFO on the receive 
> side of the
> +serial interface. A ReceiveFifoDepth value of 0 
> will use
> +the device's default FIFO depth.
> +  @param TimeoutThe requested time out for a single character in 
> microseconds.
> +This timeout applies to both the transmit and 
> receive side of the
> +interface. A Timeout value of 0 will use the 
> device's default time
> +out value.
> +  @param Parity The type of parity to use on this serial device. 
> A Parity value of
> +DefaultParity will use the device's default 
> parity value.
> +  @param DataBits   The number of data bits to use on the serial 
> device. A DataBits
> +vaule of 0 will use the device's default data 
> bit setting.
> +  @param StopBits

Re: [edk2] [PATCH V2 00/12] Upstream SerialDxe from EmbeddedPkg to MdeModulePkg

[Kinney, Michael D]

Star,

I think I am seeing some files with incorrect line endings in this patch series.

Please make sure you use the BaseTools\Scripts\PatchCheck.py script.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star 
> Zeng
> Sent: Tuesday, November 17, 2015 3:07 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH V2 00/12] Upstream SerialDxe from EmbeddedPkg to 
> MdeModulePkg
> 
> Generally, this patch series are to upstream SerialDxe from EmbeddedPkg to 
> MdeModulePkg, relatively, they are also to upstream
> SerialPortExtLib.h from EmbeddedPkg to SerialPortLib.h in MdePkg.
> 
> For your easy review, the forked code is at g...@github.com:lzeng14/edk2.git 
> branch SerialDxeV2.
> 
> * New in V2:
> According the suggestion from Laszlo Ersek , zero *Control 
> first in SerialPortGetControl() for
> EmulatorPkg/Omap35xxPkg/OvmfPkg updates.
> 
> Star Zeng (12):
>   MdePkg SerialPortLib: Upstream GetControl/SetControl/SetAttributes
> interfaces
>   PcAtChipsetPkg SerialIoLib: Add GetControl/SetControl/SetAttributes
> implementation
>   MdeModulePkg BaseSerialPortLib16550: Add
> GetControl/SetControl/SetAttributes implementation
>   MdeModulePkg: Upstream SerialDxe from EmbeddedPkg
>   EmulatorPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
>   CorebootPayloadPkg: Use SerialDxe in MdeModulePkg
>   Omap35xxPkg SerialPortLib: Add GetControl/SetControl/SetAttributes
> implementation
>   BeagleBoardPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
>   ArmPlatformPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
>   OvmfPkg XenConsoleSerialPortLib: Add
> GetControl/SetControl/SetAttributes implementation
>   ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
>   EmbeddedPkg: Remove SerialDxe and SerialPortExtLib libraries
> 
>  ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc  |   3 +-
>  ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf  |   3 +-
>  .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc|   3 +-
>  .../ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf|   3 +-
>  .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc |   3 +-
>  .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf |   3 +-
>  .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc |   3 +-
>  .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf |   3 +-
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc  |   1 -
>  .../PL011SerialPortLib/PL011SerialPortExtLib.c | 137 ---
>  .../PL011SerialPortLib/PL011SerialPortExtLib.inf   |  43 ---
>  .../PL011SerialPortLib/PL011SerialPortLib.c| 117 +-
>  ArmVirtPkg/ArmVirt.dsc.inc |   1 -
>  ArmVirtPkg/ArmVirtQemu.dsc |   2 +-
>  ArmVirtPkg/ArmVirtQemu.fdf |   2 +-
>  ArmVirtPkg/ArmVirtXen.dsc  |   3 +-
>  ArmVirtPkg/ArmVirtXen.fdf  |   3 +-
>  .../EarlyFdtPL011SerialPortLib.c   |  82 -
>  .../FdtPL011SerialPortLib/FdtPL011SerialPortLib.c  |  99 ++
>  BeagleBoardPkg/BeagleBoardPkg.dsc  |   4 +-
>  BeagleBoardPkg/BeagleBoardPkg.fdf  |   3 +-
>  CorebootPayloadPkg/CorebootPayloadPkg.fdf  |   4 +-
>  CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc  |  11 +-
>  CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc   |  11 +-
>  .../Library/PlatformBdsLib/BdsPlatform.h   |   5 +-
>  .../Library/PlatformHookLib/PlatformHookLib.c  |  56 +++
>  .../Library/PlatformHookLib/PlatformHookLib.inf|  38 ++
>  .../Library/SerialPortLib/SerialPortLib.c  | 316 -
>  .../Library/SerialPortLib/SerialPortLib.inf|  42 ---
>  CorebootPayloadPkg/SerialDxe/SerialDxe.inf |  55 ---
>  CorebootPayloadPkg/SerialDxe/SerialIo.c| 392 
>  EmbeddedPkg/EmbeddedPkg.dsc|   6 +-
>  EmbeddedPkg/Include/Library/SerialPortExtLib.h | 116 --
>  .../SerialPortExtLibNull/SerialPortExtLibNull.c|  48 ---
>  .../SerialPortExtLibNull/SerialPortExtLibNull.inf  |  30 --
>  .../TemplateSerialPortExtLib.c |  79 -
>  .../TemplateSerialPortExtLib.inf   |  36 --
>  EmbeddedPkg/SerialDxe/SerialDxe.inf|  55 ---
>  EmbeddedPkg/SerialDxe/SerialIo.c   | 391 
>  EmulatorPkg/EmulatorPkg.dsc|   3 +-
>  EmulatorPkg/EmulatorPkg.fdf|   2 +-
>  .../DxeEmuSerialPortLib/DxeEmuSerialPortLib.c  |  85 -
>  .../BaseSerialPortLib16550.c   | 341 ++
>  MdeModulePkg/MdeModulePkg.dsc  |   2 +
>  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf |  48 +++
>  MdeModulePkg/Universal/SerialDxe/SerialDxe.uni | Bin 0 -> 1892 bytes
>  .../Universal/SerialDxe/SerialDxeExtra.uni | Bin 0 -> 1324 bytes
>  

Re: [edk2] [PATCH V2 02/12] PcAtChipsetPkg SerialIoLib: Add GetControl/SetControl/SetAttributes implementation

[Kinney, Michael D]

Star,

There are a few comments included below for the SerialPortSetAttributes() 
function header comment block.  

With those comment block fixes: 

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

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star 
> Zeng
> Sent: Tuesday, November 17, 2015 3:07 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Ni, Ruiyu 
> <ruiyu...@intel.com>; Gao, Liming <liming@intel.com>
> Subject: [edk2] [PATCH V2 02/12] PcAtChipsetPkg SerialIoLib: Add 
> GetControl/SetControl/SetAttributes implementation
> 
> Cc: Michael D Kinney <michael.d.kin...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng <star.z...@intel.com>
> ---
>  PcAtChipsetPkg/Library/SerialIoLib/SerialPortLib.c | 283 
> -
>  1 file changed, 282 insertions(+), 1 deletion(-)
> 
> diff --git a/PcAtChipsetPkg/Library/SerialIoLib/SerialPortLib.c 
> b/PcAtChipsetPkg/Library/SerialIoLib/SerialPortLib.c
> index 6bf7053..5f9e06a 100644
> --- a/PcAtChipsetPkg/Library/SerialIoLib/SerialPortLib.c
> +++ b/PcAtChipsetPkg/Library/SerialIoLib/SerialPortLib.c
> @@ -1,7 +1,7 @@
>  /** @file
>UART Serial Port library functions
> 
> -  Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 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 @@ -39,6 +39,13 @@
>  #define LSR_TXRDY   0x20
>  #define LSR_RXDA0x01
>  #define DLAB0x01
> +#define MCR_DTRC0x01
> +#define MCR_RTS 0x02
> +#define MCR_LME 0x10
> +#define MSR_CTS 0x10
> +#define MSR_DSR 0x20
> +#define MSR_RI  0x40
> +#define MSR_DCD 0x80
> 
>  //-
>  // UART Settings
> @@ -219,3 +226,277 @@ SerialPortPoll (
>return (BOOLEAN) ((Data & LSR_RXDA) != 0);  }
> 
> +/**
> +  Sets the control bits on a serial device.
> +
> +  @param ControlSets the bits of Control that are settable.
> +
> +  @retval RETURN_SUCCESSThe new control bits were set on the serial 
> device.
> +  @retval RETURN_UNSUPPORTEDThe serial device does not support this 
> operation.
> +  @retval RETURN_DEVICE_ERROR   The serial device is not functioning 
> correctly.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +SerialPortSetControl (
> +  IN UINT32 Control
> +  )
> +{
> +  UINT8 Mcr;
> +
> +  //
> +  // First determine the parameter is invalid.
> +  //
> +  if ((Control & (~(EFI_SERIAL_REQUEST_TO_SEND | 
> EFI_SERIAL_DATA_TERMINAL_READY |
> +EFI_SERIAL_HARDWARE_LOOPBACK_ENABLE | 
> EFI_SERIAL_SOFTWARE_LOOPBACK_ENABLE |
> +EFI_SERIAL_HARDWARE_FLOW_CONTROL_ENABLE))) != 0) {
> +return RETURN_UNSUPPORTED;
> +  }
> +
> +  //
> +  // Read the Modem Control Register.
> +  //
> +  Mcr = IoRead8 ((UINT16) gUartBase + MCR_OFFSET);  Mcr &= (~(MCR_DTRC
> + | MCR_RTS | MCR_LME));
> +
> +  if ((Control & EFI_SERIAL_DATA_TERMINAL_READY) == 
> EFI_SERIAL_DATA_TERMINAL_READY) {
> +Mcr |= MCR_DTRC;
> +  }
> +
> +  if ((Control & EFI_SERIAL_REQUEST_TO_SEND) == EFI_SERIAL_REQUEST_TO_SEND) {
> +Mcr |= MCR_RTS;
> +  }
> +
> +  if ((Control & EFI_SERIAL_HARDWARE_LOOPBACK_ENABLE) == 
> EFI_SERIAL_HARDWARE_LOOPBACK_ENABLE) {
> +Mcr |= MCR_LME;
> +  }
> +
> +  //
> +  // Write the Modem Control Register.
> +  //
> +  IoWrite8 ((UINT16) gUartBase + MCR_OFFSET, Mcr);
> +
> +  return RETURN_SUCCESS;
> +}
> +
> +/**
> +  Retrieve the status of the control bits on a serial device.
> +
> +  @param ControlA pointer to return the current control 
> signals from the serial device.
> +
> +  @retval RETURN_SUCCESSThe control bits were read from the serial 
> device.
> +  @retval RETURN_UNSUPPORTEDThe serial device does not support this 
> operation.
> +  @retval RETURN_DEVICE_ERROR   The serial device is not functioning 
> correctly.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +SerialPortGetControl (
> +  OUT UINT32 *Control
> +  )
> +{
> +  UINT8

Re: [edk2] [PATCH V2 00/12] Upstream SerialDxe from EmbeddedPkg to MdeModulePkg

[Kinney, Michael D]

Star,

It looks like the function header comment block for SerialPortSetAttributes() 
has the same issues in all patches in this series.

Please make sure to apply my feedback to patch 1/12 to all patches in the 
series.

Thanks,

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Wednesday, November 18, 2015 11:16 AM
> To: Zeng, Star <star.z...@intel.com>; edk2-devel@lists.01.org; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Subject: RE: [edk2] [PATCH V2 00/12] Upstream SerialDxe from EmbeddedPkg to 
> MdeModulePkg
> 
> Star,
> 
> I think I am seeing some files with incorrect line endings in this patch 
> series.
> 
> Please make sure you use the BaseTools\Scripts\PatchCheck.py script.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Star Zeng
> > Sent: Tuesday, November 17, 2015 3:07 AM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [PATCH V2 00/12] Upstream SerialDxe from EmbeddedPkg
> > to MdeModulePkg
> >
> > Generally, this patch series are to upstream SerialDxe from
> > EmbeddedPkg to MdeModulePkg, relatively, they are also to upstream 
> > SerialPortExtLib.h from EmbeddedPkg to SerialPortLib.h in
> MdePkg.
> >
> > For your easy review, the forked code is at 
> > g...@github.com:lzeng14/edk2.git branch SerialDxeV2.
> >
> > * New in V2:
> > According the suggestion from Laszlo Ersek <ler...@redhat.com>, zero
> > *Control first in SerialPortGetControl() for 
> > EmulatorPkg/Omap35xxPkg/OvmfPkg updates.
> >
> > Star Zeng (12):
> >   MdePkg SerialPortLib: Upstream GetControl/SetControl/SetAttributes
> > interfaces
> >   PcAtChipsetPkg SerialIoLib: Add GetControl/SetControl/SetAttributes
> > implementation
> >   MdeModulePkg BaseSerialPortLib16550: Add
> > GetControl/SetControl/SetAttributes implementation
> >   MdeModulePkg: Upstream SerialDxe from EmbeddedPkg
> >   EmulatorPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
> >   CorebootPayloadPkg: Use SerialDxe in MdeModulePkg
> >   Omap35xxPkg SerialPortLib: Add GetControl/SetControl/SetAttributes
> > implementation
> >   BeagleBoardPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
> >   ArmPlatformPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
> >   OvmfPkg XenConsoleSerialPortLib: Add
> > GetControl/SetControl/SetAttributes implementation
> >   ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
> >   EmbeddedPkg: Remove SerialDxe and SerialPortExtLib libraries
> >
> >  ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc  |   3 +-
> >  ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf  |   3 +-
> >  .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc|   3 +-
> >  .../ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf|   3 +-
> >  .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc |   3 +-
> >  .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf |   3 +-
> >  .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc |   3 +-
> >  .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf |   3 +-
> >  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc  |   1 -
> >  .../PL011SerialPortLib/PL011SerialPortExtLib.c | 137 ---
> >  .../PL011SerialPortLib/PL011SerialPortExtLib.inf   |  43 ---
> >  .../PL011SerialPortLib/PL011SerialPortLib.c| 117 +-
> >  ArmVirtPkg/ArmVirt.dsc.inc |   1 -
> >  ArmVirtPkg/ArmVirtQemu.dsc |   2 +-
> >  ArmVirtPkg/ArmVirtQemu.fdf |   2 +-
> >  ArmVirtPkg/ArmVirtXen.dsc  |   3 +-
> >  ArmVirtPkg/ArmVirtXen.fdf  |   3 +-
> >  .../EarlyFdtPL011SerialPortLib.c   |  82 -
> >  .../FdtPL011SerialPortLib/FdtPL011SerialPortLib.c  |  99 ++
> >  BeagleBoardPkg/BeagleBoardPkg.dsc  |   4 +-
> >  BeagleBoardPkg/BeagleBoardPkg.fdf  |   3 +-
> >  CorebootPayloadPkg/CorebootPayloadPkg.fdf  |   4 +-
> >  CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc  |  11 +-
> >  CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc   |  11 +-
> >  .../Library/PlatformBdsLib/BdsPlatform.h   |   5 +-
> >  .../Library/PlatformHookLib/PlatformHookLib.c  |  56 +++
> >  .../Library/PlatformHookLib/PlatformHookLib.inf|  38 ++
> >  .../Library/SerialPortLib/SerialPortLib.c  | 316 -
> >  .../Library/SerialPortLib/SerialPortLib.inf|  42 ---
> >  CorebootPayloadPkg/SerialDx

Re: [edk2] VS tools version and code size

[Kinney, Michael D]

Hi Matthew,

I am not seeing large differences in size using the default flags from 
tools_def.txt.  

Here are some measurements of the DxeCore.efi module in MdeModulePkg/Core/Dxe.  
I have included the LZMA compressed size too because that the most common 
compression for FVs/Modules. 

TARGET  TOOL_CHAIN_TAG  ARCHSizeLZMA Compressed Size
Module  Extra Flags
=== =   =   
==  
DEBUG   VS2008x86   IA3260,640  34,172  
DxeCore.efi
DEBUG   VS2012x86   IA3263,264  35,699  
DxeCore.efi
DEBUG   VS2013x86   IA3260,224  34,489  
DxeCore.efi

RELEASE VS2008x86   IA3260,384  34,060  
DxeCore.efi -D MDEPKG_NDEBUG
RELEASE VS2012x86   IA3262,784  35,343  
DxeCore.efi -D MDEPKG_NDEBUG
RELEASE VS2013x86   IA3259,712  34,154  
DxeCore.efi -D MDEPKG_NDEBUG

DEBUG   VS2008x86   X64 77,184  35,907  
DxeCore.efi
DEBUG   VS2012x86   X64 73,696  34,507  
DxeCore.efi
DEBUG   VS2013x86   X64 73,728  34,432  
DxeCore.efi

RELEASE VS2008x86   X64 76,690  35,802  
DxeCore.efi -D MDEPKG_NDEBUG
RELEASE VS2012x86   X64 73,440  34,342  
DxeCore.efi -D MDEPKG_NDEBUG
RELEASE VS2013x86   X64 73,472  34,245  
DxeCore.efi -D MDEPKG_NDEBUG

Do you have an example of an EDK II module that exhibits the large size 
differences you are seeing using the default flags from tools_def.txt?

Thanks,

Mike

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Foster, 
Matthew I
Sent: Tuesday, September 15, 2015 1:09 PM
To: edk2-devel@lists.01.org
Subject: [edk2] VS tools version and code size

I have noticed that while compiling using Visual Studio 2008 the code size is 
much smaller compared to using a later version of Visual Studio, like 2012. 
Does anyone have any experience as to why that is? Are there any recommended 
configurations or changes needed when using a later version of Visual studio 
not add to the output code size? Thanks for any recommendations or explications.
___
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] Where do I find the system table address for an EFI app ?

[Kinney, Michael D]

Shubha,

You can run the dmem command from the UEFI shell with no parameters, and it 
will show the UFI System Table address along with other standard table 
addresses.

Shell> dmem
Memory Address 0FD6E010 200 Bytes
  0FD6E010: 49 42 49 20 53 59 53 54-32 00 02 00 48 00 00 00  *IBI SYST2...H...*
. . .
  0FD6E200: AA AA 55 55 AA AA 55 55-55 55 AA AA 55 55 AA AA  *..UU....UU..*

Valid EFI Header at Address 0FD6E010
-
System: Table Structure size 0048 revision 00020032
ConIn (0F50A28C) ConOut (0F497054) StdErr (0F50A37C)
Runtime Services 0FD6EF90
Boot Services0F89B5C0
SAL System Table 
ACPI Table   0FCEE000
ACPI 2.0 Table   0FCEE014
MPS Table
SMBIOS Table 0FD63000

For a debugger, a platform can produce the EFI_DEBUG_IMAGE_INFO_TABLE.  UEFI 
Specification Section 17.4.2 describes how a debugger can find the UEFI System 
Table address from a structure that is on a 4MB boundary with a signature and a 
CRC.  This table also provides the list of LOADED_IMAGE_PROTOCOLs for PE/COFF 
images that have been loaded, so a debugger can load symbols.

Mike 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Carsey, Jaben
> Sent: Wednesday, December 2, 2015 9:42 AM
> To: Shubha Ramani ; edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: Re: [edk2] Where do I find the system table address for an EFI app ?
> 
> I am pretty sure it’s there in a shell app also.  What entry point lib are 
> you using to build your app?
> 
> -Jaben
> 
> From: Shubha Ramani [mailto:shubharam...@yahoo.com]
> Sent: Wednesday, December 02, 2015 9:11 AM
> To: Carsey, Jaben ; edk2-devel@lists.01.org
> Subject: Re: [edk2] Where do I find the system table address for an EFI app ?
> Importance: High
> 
> Not in a Shell App though. How do you answer to the debugger when it's asking 
> for the System Table address for a shell app ?
> 
> Thanks,
> 
> Shubha
> 
> Shubha D. Ramani
> shubharam...@gmail.com
> shubharam...@yahoo.com
> 
> 
> On Tuesday, December 1, 2015 8:39 AM, "Carsey, Jaben" 
> > wrote:
> 
> Its passed as a parameter to the "main" function when your app starts.
> 
> -Jaben
> 
> > -Original Message-
> > From: edk2-devel 
> > [mailto:edk2-devel-boun...@lists.01.org]
> >  On Behalf Of
> > Shubha Ramani
> > Sent: Tuesday, December 01, 2015 8:35 AM
> > To: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Where do I find the system table address for an EFI app 
> > ?
> > Importance: High
> >
> >  I'm sorry but this was unclear. I meant where do I find the System Table
> > address for a UEFI Shell App ?The debugger is asking for it. I couldn't 
> > find it in
> > the generated *.map file.
> > Thanks
> > Shubha
> > Shubha D. ramanishubharam...@gmail.com
> > shubharam...@yahoo.com
> >
> >
> >On Monday, November 30, 2015 3:00 PM, Shubha Ramani
> > > wrote:
> >
> >
> >  I'm trying to debug it using a debugger and the debugger is asking me this
> > question.
> > I looked at the *.map file which is generated and I could not locate the 
> > System
> > Table address.
> > Thanks,
> > Shubha Shubha D. 
> > ramanishubharam...@gmail.com
> > shubharam...@yahoo.com
> 
> >
> >
> > ___
> > 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V3] MdeModulePkg: Add PciSioSerialDxe driver

[Kinney, Michael D]

Ray,

This works much better now.  I have a couple comments:

1) The #define for SERIAL_MAX_BUFFER_SIZE was removed.  This is the size of a 
software FIFO to manage data sent to the Serial I/O Protocol.  This value is 
not the same as the size of the HW FIFO in the UART.  I recommend we keep the 
#define for SERIAL_MAX_BUFFER_SIZE so the software FIFOs managed by this module 
can be adjusted in size.  For example, a UART with only a 1 byte FIFO in 
hardware could still take advantage of a 16-byte software FIFO.  We could 
consider adding a PCD to make this configurable, but the default software FIFO 
size of 16-bytes has worked for a long time, so we can keep that same value for 
now and consider adding a PCD later if failures are seen.

2) Is VerifyUartParameters () called with a ClockRate of 0 from Supported() 
because the ClockRate is not known until Start() is called?

3) The Divisor and BaudRate calculations can be improved a bit in 
VerifyUartParameters().  Use shift operations instead of divides when doing 
powers of 2.

  //
  // Divisor = ClockRate / 16 / BaudRate = ClockRate / (BaudRate * 16) = 
ClockRate / (BaudRate << 4)
  //
  *Divisor = (UINT32) DivU64x64Remainder (
   ClockRate,
   LShiftU64 (BaudRate, 4),
   
   );
  //
  // Round Divisor up by 1 if the Remainder is more than half (BaudRate * 16).
  // (BaudRate * 16) / 2 = (BaudRate * 8) = (BaudRate << 3)
  //
  if (Remainder >= LShiftU64 (BaudRate, 3)) {
*Divisor++;
  }

4) This check looks very good to make sure the computed Divisor is compatible 
with 16-bit divisor latch

if ((*Divisor == 0) || (*Divisor > MAX_UINT16)) {
  return FALSE;
}

5) This calculation of the actual baud rate looks correct, but it can be 
simplified to 32-bit math since ClockRate is UINT32 and Divisor is 16-bit 
value.  We also need to check to see if the result is 0. 

//
// Actual baud rate that the serial port will be programmed for
// should be with in 4% of requested one.
//  ActualBaudRate = ClockRate / 16 / Divisor = ClockRate / (Divisor * 16) 
= ClockRate / (Divisor << 4)
//
ActualBaudRate = ClockRate / ((UINTN)(*Divisor) << 4);
if (ActualBaudRate ==  0) {
  return FALSE;
}
Percent = DivU64x64Remainder (
MultU64x32 (BaudRate, 100),
ActualBaudRate,
NULL
);

6) Now in order to follow the UEFI spec for baud rate selection and support 
device path matching of baud rates, if the ActualBaudRate is within 4% of 
requested baud rate, then the requested baud rate can be returned.  Otherwise, 
we need to select the next lowest baud rate supported by the UART.  This means 
we really need VerifyUartParameters() to return the selected baud rate by 
changing BaudRate to a UINT64 *.

The 4% value check comes from async clock of UART.  A character Tx/Rx through a 
UART is composed of Start Bit, 7 or 8 data bits, and up to 2 stop bits.  This 
is a max of 11 bit times.  We want to make sure the 11th bit is no more than 
1/2 of a bit width off when the actual baud rate is not exactly the same as the 
requested baud rate.  With a 4% delta in frequency, the 11th bit will be off by 
44%.

If (Percent >= 96 && Percent <= 104) {
  //
  // Actual baud rate is with 4% if requested baud rate, so the requested 
baud rate is supported
  //
  return TRUE;
}
If (ActualBaudRate < *BaudRate) {
  *BaudRate = ActualBaudRate;
  return TRUE;
}

//
// ActualBaudRate is higher than requested baud rate and more than 4% 
higher than the requested value
// Increment Divisor if it is less than MAX_UINT16 and computed baud rate 
with new divisor
//
if (*Divisor == MAX_UINT16) {
  return FALSE;
}
*Divisor++;
*BaudRate = ClockRate / ((UINTN)(*Divisor) << 4);
return TRUE;

Best regards,

Mike

> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, December 8, 2015 1:08 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Tian, Feng <feng.t...@intel.com>; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Subject: [Patch V3] MdeModulePkg: Add PciSioSerialDxe driver
> 
> PciSioSerialDxe driver can manages UARTs on a SIO chip or a PCI/PCIE
> card.
> It manages the SIO instance whose last device path node is a ACPI
> device path and the HID in the ACPI device path node equals to
> EISA_PNP_ID (0x501).
> It also manages the PCI IO instance whose class code is 7/0/2 (16550
> UART). But when proper value is set to PcdPciSerialParameters, the
> driver can also manage non-standard PCI serial cards by matching
> the Vendor ID and Device ID specified in PcdPciSerialParameters.
> The PCI BAR index, IO/MMIO offset, register stride, clock rate can
> also be specified through the same 

Re: [edk2] [Patch V3] ShellPkg/mm: Fix mm to support multiple root bridge platform

[Kinney, Michael D]

Ray,

In general the code changes looks really good.  The CPU I/O protocols is only 
conditionally used, so the INF should be SOMETIMES_CONSUMES for that protocol.

I can not apply the patch because of an issue with UNI file to try running it.  
Can you please try regenerating the patch against the latest version of trunk.

Thanks,

Mike


> -Original Message-
> From: Ni, Ruiyu
> Sent: Monday, December 7, 2015 9:15 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: RE: [edk2] [Patch V3] ShellPkg/mm: Fix mm to support multiple root 
> bridge platform
> 
> The V3 version moved the HasRootBridgeIo variable definition to the beginning 
> of function.
> And I sent it through GIT command in case the attachment in V2 mail is 
> blocked by the lists.01.org.
> 
> Regards,
> Ray
> 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu 
> Ni
> Sent: Tuesday, December 8, 2015 1:13 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Subject: [edk2] [Patch V3] ShellPkg/mm: Fix mm to support multiple root 
> bridge platform
> 
> In multiple root bridge platforms, different root bridges may
> share the same segment but occupy different range of buses,
> or may occupy different segments.
> The fix is to find the correct root bridge IO instance by
> comparing not only the segment but also the bus ranges.
> It tries to access the MMIO and IO in the following order:
> PciRootBridgeIo, CpuIo and direct IO.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Michael.D.Kinney <michael.d.kin...@intel.com>
> ---
>  ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c   | 917 
> ++---
>  .../UefiShellDebug1CommandsLib.h   |   3 +-
>  .../UefiShellDebug1CommandsLib.inf |   4 +-
>  .../UefiShellDebug1CommandsLib.uni | Bin 139696 -> 139230 
> bytes
>  ShellPkg/ShellPkg.dsc  |   1 +
>  5 files changed, 464 insertions(+), 461 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c 
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c
> index ca64f2c..2f22629 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c
> @@ -2,7 +2,7 @@
>Main file for Mm shell Debug1 function.
> 
>(C) Copyright 2015 Hewlett-Packard Development Company, L.P.
> -  Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
> +  Copyright (c) 2005 - 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
> @@ -15,16 +15,25 @@
> 
>  #include "UefiShellDebug1CommandsLib.h"
>  #include 
> +#include 
>  #include 
>  #include 
> 
>  typedef enum {
> -  EfiMemory,
> -  EFIMemoryMappedIo,
> -  EfiIo,
> -  EfiPciConfig,
> -  EfiPciEConfig
> -} EFI_ACCESS_TYPE;
> +  ShellMmMemory,
> +  ShellMmMemoryMappedIo,
> +  ShellMmIo,
> +  ShellMmPci,
> +  ShellMmPciExpress
> +} SHELL_MM_ACCESS_TYPE;
> +
> +CONST UINT16 mShellMmAccessTypeStr[] = {
> +  STRING_TOKEN (STR_MM_MEM),
> +  STRING_TOKEN (STR_MM_MMIO),
> +  STRING_TOKEN (STR_MM_IO),
> +  STRING_TOKEN (STR_MM_PCI),
> +  STRING_TOKEN (STR_MM_PCIE)
> +};
> 
>  STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
>{L"-mmio", TypeFlag},
> @@ -37,161 +46,341 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
>{NULL, TypeMax}
>};
> 
> -STATIC CONST UINT64 MaxNum[9]  = { 0xff, 0x, 0x, 
> 0xULL };
> +CONST UINT64 mShellMmMaxNumber[] = {
> +  0, MAX_UINT8, MAX_UINT16, 0, MAX_UINT32, 0, 0, 0, MAX_UINT64
> +};
> +CONST EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_WIDTH mShellMmRootBridgeIoWidth[] = {
> +  0, EfiPciWidthUint8, EfiPciWidthUint16, 0, EfiPciWidthUint32, 0, 0, 0, 
> EfiPciWidthUint64
> +};
> +CONST EFI_CPU_IO_PROTOCOL_WIDTH mShellMmCpuIoWidth[] = {
> +  0, EfiCpuIoWidthUint8, EfiCpuIoWidthUint16, 0, EfiCpuIoWidthUint32, 0, 0, 
> 0, EfiCpuIoWidthUint64
> +};
> 
>  /**
> -  Read some data into a buffer from memory.
> -
> -  @param[in] WidthThe width of each read.
> -  @param[in] Addresss The memory location to start reading at.
> -  @param[in] Size The size of Buffer in Width sized units.
> -  @param

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

[Kinney, Michael D]

I think we need to evaluate both methods discussed here:

1) RTC driver use info from FADT in SetTime() when FADT is available.  Add 
event notification to RTC driver to capture FADT info before ExitBootServices().
2) Use PCD in RTC driver and in ACPI FADT table.

Advantage of (1) is that it is compatible with existing ACPI Table 
implementations.

Mike


> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, December 9, 2015 9:40 AM
> To: Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; Scott
> Duplichan <sc...@notabs.org>
> Cc: 'edk2-devel@lists.01.org' <edk2-de...@ml01.01.org>; Zeng, Star 
> <star.z...@intel.com>
> Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang 
> issue
> 
> 
> 
> On 09/12/2015 18:37, Laszlo Ersek wrote:
> > - A DXE driver that runs before *both* the ACPI platform DXE driver, and
> > this runtime DXE driver -- to be ordered by any means necessary --, *or*
> > a PEIM, sets a dynamic PCD that keys off *both* the ACPI platform DXE
> > driver and this runtime DXE driver. I think this is the best approach.
> 
> Yes, replacing RTC_ADDRESS_CENTURY with a PCD sounds like a very good idea.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

[Kinney, Michael D]

Paolo,

I agree SetTime() is not called in very many places.  But since the SetTime() 
service is added to Runtime Services Table when the RTC driver runs, the logic 
in SetTime() must be implemented to handle case where SetTime() is called 
before ACPI Tables are published.

Mike

> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, December 9, 2015 8:42 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Ni, Ruiyu 
> <ruiyu...@intel.com>; Scott Duplichan <sc...@notabs.org>
> Cc: 'edk2-devel@lists.01.org' <edk2-de...@ml01.01.org>; Zeng, Star 
> <star.z...@intel.com>
> Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang 
> issue
> 
> 
> 
> On 09/12/2015 17:33, Kinney, Michael D wrote:
> > Paolo,
> >
> > The RTC driver runs and produces the runtime services before the ACPI 
> > tables are available so what you suggest is not always
> possible.
> 
> The only place where Ruiyu's patch actually uses RTC_ADDRESS_CENTURY is
> in SetTime, and that is not used at any place other than
> SetupBrowserDxe.  The ACPI tables should be available by then, shouldn't
> they?
> 
> Paolo
> 
> > Mike
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> >> Paolo Bonzini
> >> Sent: Wednesday, December 9, 2015 3:50 AM
> >> To: Ni, Ruiyu <ruiyu...@intel.com>; Scott Duplichan <sc...@notabs.org>
> >> Cc: 'edk2-devel@lists.01.org' <edk2-de...@ml01.01.org>; Zeng, Star 
> >> <star.z...@intel.com>
> >> Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang 
> >> issue
> >>
> >>
> >>
> >> On 09/12/2015 12:16, Ni, Ruiyu wrote:
> >>> Scott, I debugged the issue further and had the below findings:
> >>> According to the ACPI spec 6.0 5.2.9 Fixed ACPI Description Table
> >>> (FADT), the FADT.Century can be set to 0 indicating the RTC doesn't
> >>> support to store century value. But the Win7 boot loader
> >>> hal!HalpInitializeCmos() will firstly read and save the FADT.Century
> >>> to a 4-byte location pointed by hal!_HalpCmosCenturyOffset. When the
> >>> FADT.Century is 0, it will save 0x32 (default value) to that
> >>> location. Later hal!HalpReadCmosTime() skips to read the century
> >>> value from CMOS when BIT 7 of the value poited by
> >>> hal!_HalpCmosCenturyOffset is set. So in order to tell Windows that
> >>> RTC doesn't support to store century, we need to set the FADT.Century
> >>> to 0x80 other than 0. In summary, if FADT.Century is 0, Win7 boot
> >>> loader reads century from 0x32; if FADT.Century & BIT7 != 0, it
> >>> doesn't read century from CMOS; otherwise, it reads century from CMOS
> >>> index FADT.Century.
> >>>
> >>> But that caused another issue. Linux code strictly follows the ACPI
> >>> spec which reads the century value from FADT.Century if it doesn't
> >>> equal to zero. If we leave 0x80 in FADT.Century, Linux kernel will
> >>> reads century from 0x80 location (actually from location 0 because
> >>> CMOS address is 7-bit). Location 0 stores the seconds of the time
> >>> which means Linux will read random century value.
> >>>
> >>> So do you agree if a platform needs to support booting both Windows
> >>> and Linux, it had better to set FADT.Century to 0x32 and save correct
> >>> century value (0x20) to CMOS address 0x32?
> >>
> >> That's fair enough, but you should not use RTC_ADDRESS_CENTURY
> >> unconditionally in PcRtcSetTime.  Instead you should read the FADT
> >> yourself and use the FADT.Century value if it is non-zero.  If it is
> >> zero, I suppose writing the century to 0x32 is the only thing you can do.
> >>
> >> Paolo
> >> ___
> >> 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 6/6] OvmfPkg: Fix VS2015 warning C4459 in XenBusDxe

[Kinney, Michael D]

Liming,

The source changes look good to me and I have verified that all 3 OVMF DSC 
files build with VS2015.  

Acked-by: Michael Kinney 

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
> Gao
> Sent: Wednesday, December 2, 2015 9:27 PM
> To: edk2-devel@lists.01.org
> Cc: Justen, Jordan L 
> Subject: [edk2] [Patch 6/6] OvmfPkg: Fix VS2015 warning C4459 in XenBusDxe
> 
> warning C4459: declaration of 'xs' hides global declaration.
> Update code to rename local variable xs to xsp to be different.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Cc: Justen Jordan 
> ---
>  OvmfPkg/XenBusDxe/XenStore.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
> index 9850f1e..61976f9 100644
> --- a/OvmfPkg/XenBusDxe/XenStore.c
> +++ b/OvmfPkg/XenBusDxe/XenStore.c
> @@ -992,9 +992,9 @@ NotifyEventChannelCheckForEvent (
>IN VOID *Context
>)
>  {
> -  XENSTORE_PRIVATE *xs;
> -  xs = (XENSTORE_PRIVATE *)Context;
> -  if (TestAndClearBit (xs->EventChannel, 
> xs->Dev->SharedInfo->evtchn_pending)) {
> +  XENSTORE_PRIVATE *xsp;
> +  xsp = (XENSTORE_PRIVATE *)Context;
> +  if (TestAndClearBit (xsp->EventChannel, 
> xsp->Dev->SharedInfo->evtchn_pending)) {
>  gBS->SignalEvent (Event);
>}
>  }
> @@ -1007,12 +1007,12 @@ NotifyEventChannelCheckForEvent (
>  STATIC
>  EFI_STATUS
>  XenStoreInitComms (
> -  XENSTORE_PRIVATE *xs
> +  XENSTORE_PRIVATE *xsp
>)
>  {
>EFI_STATUS Status;
>EFI_EVENT TimerEvent;
> -  struct xenstore_domain_interface *XenStore = xs->XenStore;
> +  struct xenstore_domain_interface *XenStore = xsp->XenStore;
> 
>Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, );
>Status = gBS->SetTimer (TimerEvent, TimerRelative,
> @@ -1029,8 +1029,8 @@ XenStoreInitComms (
>gBS->CloseEvent (TimerEvent);
> 
>Status = gBS->CreateEvent (EVT_NOTIFY_WAIT, TPL_NOTIFY,
> - NotifyEventChannelCheckForEvent, xs,
> - >EventChannelEvent);
> + NotifyEventChannelCheckForEvent, xsp,
> + >EventChannelEvent);
>ASSERT_EFI_ERROR (Status);
> 
>return Status;
> --
> 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] InsertImageRecord and Section Alignment

[Kinney, Michael D]

Lee,

It is a feature from UEFI Specification 2.5 - Section 4.6 - EFI_PROPERTIES_TABLE

In order to set the 
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA bit, runtime 
drivers need to be built so their PE/COFF code and data sections do not share 
the same 4KB page.

The log message you are seeing is not an error.  It is a warning message that a 
runtime driver was loaded that does not meet the requirements to set this bit. 

Mike

> -Original Message-
> From: Hamel, Lee M
> Sent: Thursday, December 3, 2015 11:19 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
> Subject: RE: InsertImageRecord and Section Alignment
> 
> Thanks for the solution.  Any idea why my code was fine before and now it's 
> not (the design change reason, not that tools_def.txt
> changed)?  I'm trying to understand why a change was made that caused the 
> problem.
> 
> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, December 03, 2015 11:13 AM
> To: Hamel, Lee M <lee.m.ha...@intel.com>; edk2-devel@lists.01.org; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Subject: RE: InsertImageRecord and Section Alignment
> 
> Lee,
> 
> You can fix this by adding the following to the DSC file to force modules of 
> type DXE_RUNTIME_DRIVER to use 4KB alignment.
> 
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>   MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > Hamel, Lee M
> > Sent: Thursday, December 3, 2015 10:57 AM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] InsertImageRecord and Section Alignment
> >
> > I recently synced to a newer UDK 2015 and now get this serial output many 
> > times for different images:
> >
> >   InsertImageRecord - Section Alignment(0x20) is not 4K  
> >   Image - \ReportStatusCodeRouterRuntimeDxe.pdb
> >
> > Has anyone seen this problem when syncing to UDK 2015?  I am using Visual 
> > Studio 2010 to build.
> >
> > ___
> > 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 4/6] MdeModulePkg: Fix VS2015 warning C4311 & C4312 in RegularExpressionDxe

[Kinney, Michael D]

Liming,

The source changes look good to me and I have verified that 
RegularExpressionDxe builds with VS2015.  I will let Samer do the review.

Acked-by: Michael Kinney 

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
> Gao
> Sent: Wednesday, December 2, 2015 9:27 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 4/6] MdeModulePkg: Fix VS2015 warning C4311 & C4312 in 
> RegularExpressionDxe
> 
> warning C4311: pointer truncation from 'void *' to 'unsigned long'
> warning C4312: conversion from 'unsigned long' to 'void *' of greater size
> Update code to convert type to UINTN first, then convert it to other type.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Cc: El-Haj-Mahmoud Samer 
> ---
>  .../RegularExpressionDxe/Oniguruma/enc/unicode.c   | 22 ++---
>  .../RegularExpressionDxe/Oniguruma/regexec.c   | 36 
> +++---
>  .../RegularExpressionDxe/Oniguruma/regint.h|  4 +--
>  .../RegularExpressionDxe/Oniguruma/regparse.c  | 16 +-
>  4 files changed, 39 insertions(+), 39 deletions(-)
> 
> diff --git 
> a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
> b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
> index 70a1a52..a906670 100644
> --- a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
> @@ -10920,12 +10920,12 @@ static int init_case_fold_table(void)
>if (ONIG_IS_NULL(FoldTable)) return ONIGERR_MEMORY;
>for (i = 0; i < (int )(sizeof(CaseFold)/sizeof(CaseFold_11_Type)); i++) {
>  p = [i];
> -st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t )&(p->to));
> +st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t 
> )(UINTN)&(p->to));
>}
>for (i = 0; i < (int )(sizeof(CaseFold_Locale)/sizeof(CaseFold_11_Type));
> i++) {
>  p = _Locale[i];
> -st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t )&(p->to));
> +st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t 
> )(UINTN)&(p->to));
>}
> 
>Unfold1Table = st_init_numtable_with_size(1000);
> @@ -10934,13 +10934,13 @@ static int init_case_fold_table(void)
>for (i = 0; i < (int )(sizeof(CaseUnfold_11)/sizeof(CaseUnfold_11_Type));
> i++) {
>  p1 = _11[i];
> -st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t )&(p1->to));
> +st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t 
> )(UINTN)&(p1->to));
>}
>for (i = 0;
> i < (int )(sizeof(CaseUnfold_11_Locale)/sizeof(CaseUnfold_11_Type));
> i++) {
>  p1 = _11_Locale[i];
> -st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t )&(p1->to));
> +st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t 
> )(UINTN)&(p1->to));
>}
> 
>Unfold2Table = st_init_table_with_size(_code2_hash, 200);
> @@ -10949,13 +10949,13 @@ static int init_case_fold_table(void)
>for (i = 0; i < (int )(sizeof(CaseUnfold_12)/sizeof(CaseUnfold_12_Type));
> i++) {
>  p2 = _12[i];
> -st_add_direct(Unfold2Table, (st_data_t )p2->from, (st_data_t )(>to));
> +st_add_direct(Unfold2Table, (st_data_t )(UINTN)p2->from, (st_data_t 
> )(UINTN)(>to));
>}
>for (i = 0;
> i < (int )(sizeof(CaseUnfold_12_Locale)/sizeof(CaseUnfold_12_Type));
> i++) {
>  p2 = _12_Locale[i];
> -st_add_direct(Unfold2Table, (st_data_t )p2->from, (st_data_t )(>to));
> +st_add_direct(Unfold2Table, (st_data_t )(UINTN)p2->from, (st_data_t 
> )(UINTN)(>to));
>}
> 
>Unfold3Table = st_init_table_with_size(_code3_hash, 30);
> @@ -10964,7 +10964,7 @@ static int init_case_fold_table(void)
>for (i = 0; i < (int )(sizeof(CaseUnfold_13)/sizeof(CaseUnfold_13_Type));
> i++) {
>  p3 = _13[i];
> -st_add_direct(Unfold3Table, (st_data_t )p3->from, (st_data_t )(>to));
> +st_add_direct(Unfold3Table, (st_data_t )(UINTN)p3->from, (st_data_t 
> )(UINTN)(>to));
>}
> 
> 
> @@ -11265,7 +11265,7 @@ 
> onigenc_unicode_get_case_fold_codes_by_str(OnigEncoding enc,
> }
>   }
> 
> - if (onig_st_lookup(Unfold2Table, (st_data_t )to->code,
> + if (onig_st_lookup(Unfold2Table, (st_data_t )(UINTN)to->code,
>  (void* )) != 0) {
> for (i = 0; i < z2->n; i++) {
>   if (z2->code[i] == code) continue;
> @@ -11291,7 +11291,7 @@ 
> onigenc_unicode_get_case_fold_codes_by_str(OnigEncoding enc,
> }
>   }
> 
> - if (onig_st_lookup(Unfold3Table, (st_data_t )to->code,
> + if (onig_st_lookup(Unfold3Table, (st_data_t )(UINTN)to->code,
>  (void* )) != 0) {
> for (i = 0; i < z2->n; i++) {
>   if (z2->code[i] == code) continue;
> @@ -11336,7 +11336,7 @@ 
> 

Re: [edk2] [Patch 5/6] CryptoPkg: Disable VS2015 warning C4311 in OpensslLib

[Kinney, Michael D]

Liming,

Reviewed-by: Michael Kinney 

I have also verified that builds of the CryptoPkg complete with VS2015 for IA32 
and X64.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
> Gao
> Sent: Wednesday, December 2, 2015 9:27 PM
> To: edk2-devel@lists.01.org
> Cc: Long, Qin 
> Subject: [edk2] [Patch 5/6] CryptoPkg: Disable VS2015 warning C4311 in 
> OpensslLib
> 
> Warning C4311: pointer truncation from 'type' to 'type'.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Cc: Long Qin 
> ---
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
> b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> index 20200c3..a6d511e 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> @@ -865,9 +865,10 @@
># C4305: truncation from type1 to type2 of smaller size
># C4306: conversion from type1 to type2 of greater size
># C4702: Potentially uninitialized local variable name used
> +  # C4311: pointer truncation from 'type' to 'type'
>#
>MSFT:*_*_IA32_CC_FLAGS= -U_WIN32 -U_WIN64 -U_MSC_VER $(OPENSSL_FLAGS) 
> /wd4244 /wd4701 /wd4702 /wd4706
> -  MSFT:*_*_X64_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER $(OPENSSL_FLAGS) 
> /wd4133 /wd4244 /wd4245 /wd4267 /wd4701
> /wd4305 /wd4306 /wd4702 /wd4706
> +  MSFT:*_*_X64_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER $(OPENSSL_FLAGS) 
> /wd4133 /wd4244 /wd4245 /wd4267 /wd4701
> /wd4305 /wd4306 /wd4702 /wd4706 /wd4311
>MSFT:*_*_IPF_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER $(OPENSSL_FLAGS) 
> /wd4133 /wd4244 /wd4245 /wd4267 /wd4701
> /wd4305 /wd4306 /wd4702 /wd4706
> 
>INTEL:*_*_IA32_CC_FLAGS   = -U_WIN32 -U_WIN64 -U_MSC_VER -U__ICC 
> $(OPENSSL_FLAGS) /w
> --
> 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 3/6] MdeModulePkg: Fix VS2015 warning C4456 in RegularExpressionDxe

[Kinney, Michael D]

Liming,

The source changes look good to me and I have verified that 
RegularExpressionDxe builds with VS2015.  I will let Samer do the review.

Acked-by: Michael Kinney 

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
> Gao
> Sent: Wednesday, December 2, 2015 9:27 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 3/6] MdeModulePkg: Fix VS2015 warning C4456 in 
> RegularExpressionDxe
> 
> warning C4456: declaration of 'q' hides previous local declaration.
> Update code to use the different local variable name.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Cc: El-Haj-Mahmoud Samer 
> ---
>  .../Universal/RegularExpressionDxe/Oniguruma/regexec.c   | 16 
> 
>  .../Universal/RegularExpressionDxe/Oniguruma/regint.h|  4 ++--
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regexec.c
> b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regexec.c
> index de5839a..5e3ffa1 100644
> --- a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regexec.c
> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regexec.c
> @@ -1442,7 +1442,7 @@ match_at(regex_t* reg, const UChar* str, const UChar* 
> end,
>  case OP_EXACT1_IC:  MOP_IN(OP_EXACT1_IC);
>{
>   int len;
> - UChar *q, lowbuf[ONIGENC_MBC_CASE_FOLD_MAXLEN];
> + UChar *q1, lowbuf[ONIGENC_MBC_CASE_FOLD_MAXLEN];
> 
>   DATA_ENSURE(1);
>   len = ONIGENC_MBC_CASE_FOLD(encode,
> @@ -1450,12 +1450,12 @@ match_at(regex_t* reg, const UChar* str, const UChar* 
> end,
>   case_fold_flag,
>   , end, lowbuf);
>   DATA_ENSURE(0);
> - q = lowbuf;
> + q1 = lowbuf;
>   while (len-- > 0) {
> -   if (*p != *q) {
> +   if (*p != *q1) {
>  goto fail;
>}
> -   p++; q++;
> +   p++; q1++;
>   }
>}
>MOP_OUT;
> @@ -1531,7 +1531,7 @@ match_at(regex_t* reg, const UChar* str, const UChar* 
> end,
>  case OP_EXACTN_IC:  MOP_IN(OP_EXACTN_IC);
>{
>   int len;
> - UChar *q, *endp, lowbuf[ONIGENC_MBC_CASE_FOLD_MAXLEN];
> + UChar *qn, *endp, lowbuf[ONIGENC_MBC_CASE_FOLD_MAXLEN];
> 
>   GET_LENGTH_INC(tlen, p);
>   endp = p + tlen;
> @@ -1544,10 +1544,10 @@ match_at(regex_t* reg, const UChar* str, const UChar* 
> end,
> case_fold_flag,
> , end, lowbuf);
> DATA_ENSURE(0);
> -   q = lowbuf;
> +   qn = lowbuf;
> while (len-- > 0) {
> - if (*p != *q) goto fail;
> - p++; q++;
> + if (*p != *qn) goto fail;
> + p++; qn++;
> }
>   }
>}
> diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regint.h
> b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regint.h
> index 2db3b70..44589bf 100644
> --- a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regint.h
> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regint.h
> @@ -329,8 +329,8 @@ typedef Bits*  BitSetRef;
>  #define SIZE_BITSETsizeof(BitSet)
> 
>  #define BITSET_CLEAR(bs) do {\
> -  int i;\
> -  for (i = 0; i < (int )BITSET_SIZE; i++) { (bs)[i] = 0; }   \
> +  int id;\
> +  for (id = 0; id < (int )BITSET_SIZE; id++) { (bs)[id] = 0; }   \
>  } while (0)
> 
>  #define BS_ROOM(bs,pos)(bs)[pos / BITS_IN_ROOM]
> --
> 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] InsertImageRecord and Section Alignment

[Kinney, Michael D]

Lee,

You can fix this by adding the following to the DSC file to force modules of 
type DXE_RUNTIME_DRIVER to use 4KB alignment.

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
  MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hamel, 
> Lee M
> Sent: Thursday, December 3, 2015 10:57 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] InsertImageRecord and Section Alignment
> 
> I recently synced to a newer UDK 2015 and now get this serial output many 
> times for different images:
> 
>   InsertImageRecord - Section Alignment(0x20) is not 4K  
>   Image - \ReportStatusCodeRouterRuntimeDxe.pdb
> 
> Has anyone seen this problem when syncing to UDK 2015?  I am using Visual 
> Studio 2010 to build.
> 
> ___
> 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] InsertImageRecord and Section Alignment

[Kinney, Michael D]

Laszlo,

That is a good question.  If a platform requires 
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA to be set, then 
it is an error condition.  That is why it is an error message and not a warning 
message.

We could consider changing this specific message to a warning, and add one 
error message from the \MdeModulePkg\Universal\PropertiesTableAttributesDxe 
module.  That way, only platforms that include this module will get an error 
message if any runtime modules for not use 4KB aligned.

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, December 3, 2015 3:36 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: Hamel, Lee M <lee.m.ha...@intel.com>; edk2-devel@lists.01.org 
> <edk2-de...@ml01.01.org>
> Subject: Re: [edk2] InsertImageRecord and Section Alignment
> 
> On 12/03/15 21:16, Kinney, Michael D wrote:
> > Lee,
> >
> > It is a feature from UEFI Specification 2.5 - Section 4.6 -
> > EFI_PROPERTIES_TABLE
> >
> > In order to set the
> > EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA bit,
> > runtime drivers need to be built so their PE/COFF code and data
> > sections do not share the same 4KB page.
> >
> > The log message you are seeing is not an error.  It is a warning
> > message that a runtime driver was loaded that does not meet the
> > requirements to set this bit.
> 
> Should the message be downgraded from EFI_D_ERROR to EFI_D_WARN
> ("MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c")?
> 
> Thanks
> Laszlo
> 
> >
> > Mike
> >
> >> -Original Message-
> >> From: Hamel, Lee M
> >> Sent: Thursday, December 3, 2015 11:19 AM
> >> To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
> >> Subject: RE: InsertImageRecord and Section Alignment
> >>
> >> Thanks for the solution.  Any idea why my code was fine before and now 
> >> it's not (the design change reason, not that tools_def.txt
> >> changed)?  I'm trying to understand why a change was made that caused the 
> >> problem.
> >>
> >> -Original Message-
> >> From: Kinney, Michael D
> >> Sent: Thursday, December 03, 2015 11:13 AM
> >> To: Hamel, Lee M <lee.m.ha...@intel.com>; edk2-devel@lists.01.org; Kinney, 
> >> Michael D <michael.d.kin...@intel.com>
> >> Subject: RE: InsertImageRecord and Section Alignment
> >>
> >> Lee,
> >>
> >> You can fix this by adding the following to the DSC file to force modules 
> >> of type DXE_RUNTIME_DRIVER to use 4KB alignment.
> >>
> >> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> >>   MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> >>
> >> Mike
> >>
> >>> -Original Message-
> >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> >>> Hamel, Lee M
> >>> Sent: Thursday, December 3, 2015 10:57 AM
> >>> To: edk2-devel@lists.01.org
> >>> Subject: [edk2] InsertImageRecord and Section Alignment
> >>>
> >>> I recently synced to a newer UDK 2015 and now get this serial output many 
> >>> times for different images:
> >>>
> >>>   InsertImageRecord - Section Alignment(0x20) is not 4K  
> >>>   Image - \ReportStatusCodeRouterRuntimeDxe.pdb
> >>>
> >>> Has anyone seen this problem when syncing to UDK 2015?  I am using Visual 
> >>> Studio 2010 to build.
> >>>
> >>> ___
> >>> 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
> >

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

Re: [edk2] [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver

[Kinney, Michael D]

Hi Ray,

I agree a UINT64 Offset would be good for the Offset field.  It would also be 
good to order the fields and pad the structure so they are naturally aligned.  
Maybe like the following with some comment changes:

typedef struct {
  UINT16  VendorId;   ///< Vendor ID to match the PCI device.  The value 
0x terminates the list of entries.
  UINT16  DeviceId;   ///< Device ID to match the PCI device
  UINT32  ClockRate;  ///< UART clock rate.  Set to 0 for default clock 
rate of 1843200 Hz
  UINT64  Offset; ///< The byte offset into to the BAR
  UINT8   BarIndex;   ///< Which BAR to get the UART base address
  UINT8   RegisterStride; ///< UART register stride in bytes.  Set to 0 for 
default register stride of 1 byte.
  UINT8  Reserved[6];
} PCI_SERIAL_PARAMETER;

You need to add this module to the MdeModulePkg DSC file.

The code is currently limited to 115200 baud.  There are many UARTs that 
support higher baud rates, so this restriction needs to be removed.

If a non-standard ClockRate is used, then the actual baud rate may not exactly 
match the expected baud rate, but as long as we are within a few percent, the 
UART is stable.

I would like to use this driver as a replacement for the UART driver for Quark 
that I have posted on GitHub at: 


https://github.com/mdkinney/edk2/tree/Quark/QuarkSocPkg/QuarkSouthCluster/Uart/Dxe

It has support for baud rate up to 921600 and closest baud rate match with a 
few percent and support for larger Tx FIFOs and extra flushes of the Tx FIFO 
when doing a Reset or a UART config change.  Please let me know if you want me 
to help merge in some of those features to your patch.

Thanks,

Mike

> -Original Message-
> From: Tian, Feng
> Sent: Wednesday, December 2, 2015 9:13 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Cc: edk2-devel@lists.01.org; Tian, Feng <feng.t...@intel.com>
> Subject: RE: [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> 
> Suggest to use UINT64 for Offset field to be consistent with PciIo protocol 
> definition.
> 
> Others look good to me
> 
> 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 Ni, 
> Ruiyu
> Sent: Monday, November 30, 2015 10:12
> To: Kinney, Michael D
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> 
> Mike,
> Could you please review whether the PCD structure defined as below is good?
> 
> +#pragma pack(1)
> +///
> +/// PcdPciSerialParameters contains zero or more instances of the below 
> structure.
> +/// If a PCI device contains multiple UARTs, PcdPciSerialParameters needs to 
> contain
> +/// two instances of the below structure, with the VendorId and DeviceId 
> equals to the
> +/// device ID and vendor ID of the device. If the PCI device uses the first 
> two BARs
> +/// to support multiple UARTs, BarIndex of first instance equals to 0 and 
> BarIndex of
> +/// second one equals to 1; if the PCI device uses the first BAR to support 
> multiple
> +/// UARTs, BarIndex of both instance equals to 0 and Offset of first 
> instance equals
> +/// to 0 while Offset of second one equals to some value bigger or equal to 
> 8.
> +/// For certain UART whose register needs to be accessed in DWORD aligned 
> address,
> +/// RegisterStride equals to 4.
> +///
> +typedef struct {
> +  UINT16  VendorId;   ///< Vendor ID to match the PCI device, 0x 
> terminates the entries
> +  UINT16  DeviceId;   ///< Device ID to match the PCI device
> +  UINT8   BarIndex;   ///< Which BAR to get the UART base address
> +  UINT16  Offset; ///< The offset to the BAR
> +  UINT8   RegisterStride; ///< UART register stride, 0 to use 1 as register 
> stride
> +  UINT32  ClockRate;  ///< UART clock rate, 0 to use default clock rate 
> 1843200
> +} PCI_SERIAL_PARAMETER;> +#pragma pack()
> 
> Regards,
> Ray
> 
> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, November 25, 2015 10:30 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Tian, Feng <feng.t...@intel.com>; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Subject: [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> 
> PciSioSerialDxe driver can manages UARTs on a SIO chip or a PCI/PCIE
> card.
> It manages the SIO instance whose last device path node is a ACPI
> device path and the HID in the ACPI device path node equals to
> EISA_PNP_ID (0x501).
> It also manages the PCI IO instance whose class code is 7/0/2 (16550
> UART). But when prope

Re: [edk2] [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver

[Kinney, Michael D]

Ray,

I tried to build this module into a platform, and I am getting function name 
collisions with BaseSerialPortLib16550 for the symbols:

SerialPortReadRegister
SerialPortWriteRegister

I recommend you change the names of these 2 functions.

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, December 3, 2015 4:00 PM
> To: Tian, Feng <feng.t...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: RE: [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> 
> Hi Ray,
> 
> I agree a UINT64 Offset would be good for the Offset field.  It would also be 
> good to order the fields and pad the structure so they are
> naturally aligned.  Maybe like the following with some comment changes:
> 
> typedef struct {
>   UINT16  VendorId;   ///< Vendor ID to match the PCI device.  The value 
> 0x terminates the list of entries.
>   UINT16  DeviceId;   ///< Device ID to match the PCI device
>   UINT32  ClockRate;  ///< UART clock rate.  Set to 0 for default clock 
> rate of 1843200 Hz
>   UINT64  Offset; ///< The byte offset into to the BAR
>   UINT8   BarIndex;   ///< Which BAR to get the UART base address
>   UINT8   RegisterStride; ///< UART register stride in bytes.  Set to 0 for 
> default register stride of 1 byte.
>   UINT8  Reserved[6];
> } PCI_SERIAL_PARAMETER;
> 
> You need to add this module to the MdeModulePkg DSC file.
> 
> The code is currently limited to 115200 baud.  There are many UARTs that 
> support higher baud rates, so this restriction needs to be
> removed.
> 
> If a non-standard ClockRate is used, then the actual baud rate may not 
> exactly match the expected baud rate, but as long as we are
> within a few percent, the UART is stable.
> 
> I would like to use this driver as a replacement for the UART driver for 
> Quark that I have posted on GitHub at:
> 
>   
> https://github.com/mdkinney/edk2/tree/Quark/QuarkSocPkg/QuarkSouthCluster/Uart/Dxe
> 
> It has support for baud rate up to 921600 and closest baud rate match with a 
> few percent and support for larger Tx FIFOs and extra
> flushes of the Tx FIFO when doing a Reset or a UART config change.  Please 
> let me know if you want me to help merge in some of
> those features to your patch.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Tian, Feng
> > Sent: Wednesday, December 2, 2015 9:13 PM
> > To: Ni, Ruiyu <ruiyu...@intel.com>; Kinney, Michael D 
> > <michael.d.kin...@intel.com>
> > Cc: edk2-devel@lists.01.org; Tian, Feng <feng.t...@intel.com>
> > Subject: RE: [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> >
> > Suggest to use UINT64 for Offset field to be consistent with PciIo protocol 
> > definition.
> >
> > Others look good to me
> >
> > 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 Ni, 
> > Ruiyu
> > Sent: Monday, November 30, 2015 10:12
> > To: Kinney, Michael D
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> >
> > Mike,
> > Could you please review whether the PCD structure defined as below is good?
> >
> > +#pragma pack(1)
> > +///
> > +/// PcdPciSerialParameters contains zero or more instances of the below 
> > structure.
> > +/// If a PCI device contains multiple UARTs, PcdPciSerialParameters needs 
> > to contain
> > +/// two instances of the below structure, with the VendorId and DeviceId 
> > equals to the
> > +/// device ID and vendor ID of the device. If the PCI device uses the 
> > first two BARs
> > +/// to support multiple UARTs, BarIndex of first instance equals to 0 and 
> > BarIndex of
> > +/// second one equals to 1; if the PCI device uses the first BAR to 
> > support multiple
> > +/// UARTs, BarIndex of both instance equals to 0 and Offset of first 
> > instance equals
> > +/// to 0 while Offset of second one equals to some value bigger or equal 
> > to 8.
> > +/// For certain UART whose register needs to be accessed in DWORD aligned 
> > address,
> > +/// RegisterStride equals to 4.
> > +///
> > +typedef struct {
> > +  UINT16  VendorId;   ///< Vendor ID to match the PCI device, 0x 
> > terminates the entries
> > +  UINT16  DeviceId;   ///< Device ID to match the PCI device
> >

Re: [edk2] [PATCH 1/3] BaseTools/Scripts: Add ConvertUtf16ToUtf8.py script

[Kinney, Michael D]

Jordan,

Do the UTF-8 files generated include a BOM?

Just in case someone depends on UNI files in UTF-16LE format, do you think it 
makes sense for this script to support conversion to from UTF-8 to UTF-16LE 
too?  Or add a second script to that conversion?

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
> Justen
> Sent: Wednesday, December 2, 2015 2:17 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Justen, Jordan L 
> ; Gao, Liming 
> Subject: [edk2] [PATCH 1/3] BaseTools/Scripts: Add ConvertUtf16ToUtf8.py 
> script
> 
> This script uses python codecs to convert .uni string files from
> utf-16 to utf-8.
> 
> The advantages of utf-8 data:
>  * Generally smaller files
>  * More commonly supported by editors
>  * Not treated as binary data in patch files
> 
> Cc: Yonghong Zhu 
> Cc: Liming Gao 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen 
> ---
>  BaseTools/Scripts/ConvertUtf16ToUtf8.py | 123 
> 
>  1 file changed, 123 insertions(+)
>  create mode 100755 BaseTools/Scripts/ConvertUtf16ToUtf8.py
> 
> diff --git a/BaseTools/Scripts/ConvertUtf16ToUtf8.py 
> b/BaseTools/Scripts/ConvertUtf16ToUtf8.py
> new file mode 100755
> index 000..5f54603
> --- /dev/null
> +++ b/BaseTools/Scripts/ConvertUtf16ToUtf8.py
> @@ -0,0 +1,123 @@
> +## @file
> +#  Check a patch for various format issues
> +#
> +#  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
> +#
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> +#  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> +#  EXPRESS OR IMPLIED.
> +#
> +
> +from __future__ import print_function
> +
> +VersionNumber = '0.1'
> +__copyright__ = "Copyright (c) 2015, Intel Corporation  All rights reserved."
> +
> +import argparse
> +import codecs
> +import os
> +import sys
> +
> +try:
> +from io import StringIO
> +except ImportError:
> +from StringIO import StringIO
> +
> +class ConvertOneArg:
> +"""Converts utf-16 to utf-8 for one command line argument.
> +
> +   This could be a single file, or a directory.
> +"""
> +
> +def __init__(self, source):
> +self.source = source
> +
> +self.ok = True
> +
> +if not os.path.exists(source):
> +self.ok = False
> +elif os.path.isdir(source):
> +for (root, dirs, files) in os.walk(source):
> +files = filter(lambda a: a.endswith('.uni'), files)
> +for filename in files:
> +path = os.path.join(root, filename)
> +self.ok &= self.convert_one_file(path)
> +if not self.ok:
> +break
> +
> +if not self.ok:
> +break
> +else:
> +self.ok &= self.convert_one_file(source)
> +
> +def convert_one_file(self, source):
> +#
> +# Read file
> +#
> +utf16_file = open(source, mode='rb')
> +file_content = utf16_file.read()
> +utf16_file.close()
> +
> +#
> +# Detect UTF-16 Byte Order Mark at beginning of file.
> +#
> +if not (file_content.startswith(codecs.BOM_UTF16_BE) or
> +file_content.startswith(codecs.BOM_UTF16_LE)):
> +print(source + ": already utf-8")
> +return True
> +
> +#
> +# Decode utf-16 string data
> +#
> +str_content = file_content.decode('utf-16', 'ignore')
> +
> +#
> +# Encode string data to utf-8
> +#
> +utf8_content = str_content.encode('utf-8', 'ignore')
> +
> +#
> +# Write converted utf-8 data back to file
> +#
> +utf8_file = open(source, mode='wb')
> +utf8_file.write(utf8_content)
> +utf8_file.close()
> +
> +print(source + ": converted, size", len(file_content), '=>', 
> len(utf8_content))
> +return True
> +
> +
> +class ConvertUtf16ToUtf8App:
> +"""Converts files to utf-8 based on the command line arguments."""
> +
> +def __init__(self):
> +self.parse_options()
> +sources = self.args.source
> +
> +self.ok = True
> +for patch in sources:
> +self.process_one_arg(patch)
> +
> +if self.ok:
> +self.retval = 0
> +else:
> +self.retval = -1
> +
> +def process_one_arg(self, arg):
> +self.ok 

Re: [edk2] [Patch 2/6] MdeModulePkg: Fix VS2015 warning C4459 in DriverSampleDxe

[Kinney, Michael D]

Liming,

Reviewed-by: Michael Kinney 

I have also verified that builds of the MdeModulePkg/Universal/DriverSampleDxe 
complete with VS2015 for IA32 and X64.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
> Gao
> Sent: Wednesday, December 2, 2015 9:27 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 2/6] MdeModulePkg: Fix VS2015 warning C4459 in 
> DriverSampleDxe
> 
> warning C4459: declaration of 'PrivateData' hides global declaration.
> Update DriverSampleDxe to rename global variable name to be different.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  .../Universal/DriverSampleDxe/DriverSample.c   | 72 
> +++---
>  1 file changed, 36 insertions(+), 36 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> index 2f77d39..8ec1d4e 100644
> --- a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> +++ b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> @@ -21,7 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  CHAR16 VariableName[] = L"MyIfrNVData";
>  CHAR16 MyEfiVar[] = L"MyEfiVar";
>  EFI_HANDLE  DriverHandle[2] = {NULL, NULL};
> -DRIVER_SAMPLE_PRIVATE_DATA  *PrivateData = NULL;
> +DRIVER_SAMPLE_PRIVATE_DATA  *mPrivateData = NULL;
>  EFI_EVENT   mEvent;
> 
>  HII_VENDOR_DEVICE_PATH  mHiiVendorDevicePath0 = {
> @@ -1895,17 +1895,17 @@ DriverSampleInit (
>//
>// Initialize driver private data
>//
> -  PrivateData = AllocateZeroPool (sizeof (DRIVER_SAMPLE_PRIVATE_DATA));
> -  if (PrivateData == NULL) {
> +  mPrivateData = AllocateZeroPool (sizeof (DRIVER_SAMPLE_PRIVATE_DATA));
> +  if (mPrivateData == NULL) {
>  return EFI_OUT_OF_RESOURCES;
>}
> 
> -  PrivateData->Signature = DRIVER_SAMPLE_PRIVATE_SIGNATURE;
> +  mPrivateData->Signature = DRIVER_SAMPLE_PRIVATE_SIGNATURE;
> 
> -  PrivateData->ConfigAccess.ExtractConfig = ExtractConfig;
> -  PrivateData->ConfigAccess.RouteConfig = RouteConfig;
> -  PrivateData->ConfigAccess.Callback = DriverCallback;
> -  PrivateData->PasswordState = BROWSER_STATE_VALIDATE_PASSWORD;
> +  mPrivateData->ConfigAccess.ExtractConfig = ExtractConfig;
> +  mPrivateData->ConfigAccess.RouteConfig = RouteConfig;
> +  mPrivateData->ConfigAccess.Callback = DriverCallback;
> +  mPrivateData->PasswordState = BROWSER_STATE_VALIDATE_PASSWORD;
> 
>//
>// Locate Hii Database protocol
> @@ -1914,7 +1914,7 @@ DriverSampleInit (
>if (EFI_ERROR (Status)) {
>  return Status;
>}
> -  PrivateData->HiiDatabase = HiiDatabase;
> +  mPrivateData->HiiDatabase = HiiDatabase;
> 
>//
>// Locate HiiString protocol
> @@ -1923,7 +1923,7 @@ DriverSampleInit (
>if (EFI_ERROR (Status)) {
>  return Status;
>}
> -  PrivateData->HiiString = HiiString;
> +  mPrivateData->HiiString = HiiString;
> 
>//
>// Locate Formbrowser2 protocol
> @@ -1932,7 +1932,7 @@ DriverSampleInit (
>if (EFI_ERROR (Status)) {
>  return Status;
>}
> -  PrivateData->FormBrowser2 = FormBrowser2;
> +  mPrivateData->FormBrowser2 = FormBrowser2;
> 
>//
>// Locate ConfigRouting protocol
> @@ -1941,7 +1941,7 @@ DriverSampleInit (
>if (EFI_ERROR (Status)) {
>  return Status;
>}
> -  PrivateData->HiiConfigRouting = HiiConfigRouting;
> +  mPrivateData->HiiConfigRouting = HiiConfigRouting;
> 
>//
>// Locate keyword handler protocol
> @@ -1950,19 +1950,19 @@ DriverSampleInit (
>if (EFI_ERROR (Status)) {
>  return Status;
>}
> -  PrivateData->HiiKeywordHandler = HiiKeywordHandler;
> +  mPrivateData->HiiKeywordHandler = HiiKeywordHandler;
> 
>Status = gBS->InstallMultipleProtocolInterfaces (
>[0],
>,
>,
>,
> -  >ConfigAccess,
> +  >ConfigAccess,
>NULL
>);
>ASSERT_EFI_ERROR (Status);
> 
> -  PrivateData->DriverHandle[0] = DriverHandle[0];
> +  mPrivateData->DriverHandle[0] = DriverHandle[0];
> 
>//
>// Publish our HII data
> @@ -1978,7 +1978,7 @@ DriverSampleInit (
>  return EFI_OUT_OF_RESOURCES;
>}
> 
> -  PrivateData->HiiHandle[0] = HiiHandle[0];
> +  mPrivateData->HiiHandle[0] = HiiHandle[0];
> 
>//
>// Publish another Fromset
> @@ -1988,12 +1988,12 @@ DriverSampleInit (
>,
>,
>,
> -  >ConfigAccess,
> +  >ConfigAccess,
>NULL
>);
>ASSERT_EFI_ERROR (Status);
> 
> -  PrivateData->DriverHandle[1] = DriverHandle[1];
> +  mPrivateData->DriverHandle[1] = DriverHandle[1];
> 
>HiiHandle[1] = HiiAddPackages (
> 

Re: [edk2] InsertImageRecord and Section Alignment

[Kinney, Michael D]

Jiewen,

I agree that is a good place to put the error message.

Mike

> -Original Message-
> From: Yao, Jiewen
> Sent: Sunday, December 6, 2015 7:06 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek 
> <ler...@redhat.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>
> Cc: Hamel, Lee M <lee.m.ha...@intel.com>; edk2-devel@lists.01.org 
> <edk2-de...@ml01.01.org>
> Subject: RE: [edk2] InsertImageRecord and Section Alignment
> 
> Hi Mike
> I agree that we can change this from ERROR to WARNING, and only add 1 ERROR 
> message.
> 
> However, the \MdeModulePkg\Universal\PropertiesTableAttributesDxe module is 
> optional module, because a platform may use its
> own module to set attributes for ACPINvs or reserved.
> 
> How about we add error message when install this table in 
> DxeCore.InstallPropertiesTable().
> if ((mPropertiesTable.MemoryProtectionAttribute &
> EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA) == 0) {
>   DEBUG ((EFI_D_ERROR, "MemoryProtectionAttribute NON_EXECUTABLE_PE_DATA  
> not set\n")); <== New line
>   return ;
> }
> 
> Thank you
> Yao Jiewen
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Kinney, Michael D
> Sent: Friday, December 04, 2015 8:27 AM
> To: Laszlo Ersek; Kinney, Michael D
> Cc: Hamel, Lee M; edk2-devel@lists.01.org
> Subject: Re: [edk2] InsertImageRecord and Section Alignment
> 
> Laszlo,
> 
> That is a good question.  If a platform requires 
> EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA to
> be set, then it is an error condition.  That is why it is an error message 
> and not a warning message.
> 
> We could consider changing this specific message to a warning, and add one 
> error message from the
> \MdeModulePkg\Universal\PropertiesTableAttributesDxe module.  That way, only 
> platforms that include this module will get an error
> message if any runtime modules for not use 4KB aligned.
> 
> Mike
> 
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Thursday, December 3, 2015 3:36 PM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>
> > Cc: Hamel, Lee M <lee.m.ha...@intel.com>; edk2-devel@lists.01.org
> > <edk2-de...@ml01.01.org>
> > Subject: Re: [edk2] InsertImageRecord and Section Alignment
> >
> > On 12/03/15 21:16, Kinney, Michael D wrote:
> > > Lee,
> > >
> > > It is a feature from UEFI Specification 2.5 - Section 4.6 -
> > > EFI_PROPERTIES_TABLE
> > >
> > > In order to set the
> > > EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA bit,
> > > runtime drivers need to be built so their PE/COFF code and data
> > > sections do not share the same 4KB page.
> > >
> > > The log message you are seeing is not an error.  It is a warning
> > > message that a runtime driver was loaded that does not meet the
> > > requirements to set this bit.
> >
> > Should the message be downgraded from EFI_D_ERROR to EFI_D_WARN
> > ("MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c")?
> >
> > Thanks
> > Laszlo
> >
> > >
> > > Mike
> > >
> > >> -Original Message-
> > >> From: Hamel, Lee M
> > >> Sent: Thursday, December 3, 2015 11:19 AM
> > >> To: Kinney, Michael D <michael.d.kin...@intel.com>;
> > >> edk2-devel@lists.01.org
> > >> Subject: RE: InsertImageRecord and Section Alignment
> > >>
> > >> Thanks for the solution.  Any idea why my code was fine before and
> > >> now it's not (the design change reason, not that tools_def.txt changed)? 
> > >>  I'm trying to understand why a change was made that
> caused the problem.
> > >>
> > >> -Original Message-
> > >> From: Kinney, Michael D
> > >> Sent: Thursday, December 03, 2015 11:13 AM
> > >> To: Hamel, Lee M <lee.m.ha...@intel.com>; edk2-devel@lists.01.org;
> > >> Kinney, Michael D <michael.d.kin...@intel.com>
> > >> Subject: RE: InsertImageRecord and Section Alignment
> > >>
> > >> Lee,
> > >>
> > >> You can fix this by adding the following to the DSC file to force 
> > >> modules of type DXE_RUNTIME_DRIVER to use 4KB alignment.
> > >>
> > >> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> > >>   MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> >

Re: [edk2] [PATCH 1/3] BaseTools/Scripts: Add ConvertUtf16ToUtf8.py script

[Kinney, Michael D]

Jordan,

Good.  I was hoping it did not add the BOM...because that would still be a 
binary file I think.

I really appreciate you working on the reverse conversion.  

Mike

> -Original Message-
> From: Justen, Jordan L
> Sent: Wednesday, December 2, 2015 4:25 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org; 
> Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Gao, Liming <liming@intel.com>
> Subject: RE: [edk2] [PATCH 1/3] BaseTools/Scripts: Add ConvertUtf16ToUtf8.py 
> script
> 
> On 2015-12-02 15:30:42, Kinney, Michael D wrote:
> > Jordan,
> >
> > Do the UTF-8 files generated include a BOM?
> 
> https://en.wikipedia.org/wiki/Byte_order_mark#UTF-8
> 
> "The UTF-8 representation of the BOM is the byte sequence
>  0xEF,0xBB,0xBF."
> 
>  ...
> 
> "The Unicode Standard permits the BOM in UTF-8, but does not require
>  or recommend its use."
> 
> This conversion script does not add a BOM to the files. I think the
> BOM might be rarely used, so I wouldn't be surprised if there were
> some applications that might be confused by it.
> 
> > Just in case someone depends on UNI files in UTF-16LE format, do you
> > think it makes sense for this script to support conversion to from
> > UTF-8 to UTF-16LE too? Or add a second script to that conversion?
> 
> I don't think the BOM issue should prevent converting back to utf-16.
> (We can look for the lack of the UTF-16 BOM.)
> 
> I considered if the script should handle both conversions, but I'm not
> too interested in the utf-8 => utf-16 conversion, so I figured I'd
> take the easy path. :)
> 
> Do I need to do the other conversion to let this change proceed? Or
> can someone on your team handle that? (If it is actually needed...)
> 
> I can also rename the script to ConvertUni.py and add a --utf-8 switch
> for now. Then we could later add --utf-16 to the same script. (Darn,
> now I've thought about it enough that I'll probably just add the other
> conversion. :)
> 
> -Jordan
> 
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > > Jordan Justen
> > > Sent: Wednesday, December 2, 2015 2:17 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Carsey, Jaben <jaben.car...@intel.com>; Justen, Jordan L 
> > > <jordan.l.jus...@intel.com>; Gao, Liming <liming@intel.com>
> > > Subject: [edk2] [PATCH 1/3] BaseTools/Scripts: Add ConvertUtf16ToUtf8.py 
> > > script
> > >
> > > This script uses python codecs to convert .uni string files from
> > > utf-16 to utf-8.
> > >
> > > The advantages of utf-8 data:
> > >  * Generally smaller files
> > >  * More commonly supported by editors
> > >  * Not treated as binary data in patch files
> > >
> > > Cc: Yonghong Zhu <yonghong@intel.com>
> > > Cc: Liming Gao <liming@intel.com>
> > > Cc: Jaben Carsey <jaben.car...@intel.com>
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
> > > ---
> > >  BaseTools/Scripts/ConvertUtf16ToUtf8.py | 123 
> > > 
> > >  1 file changed, 123 insertions(+)
> > >  create mode 100755 BaseTools/Scripts/ConvertUtf16ToUtf8.py
> > >
> > > diff --git a/BaseTools/Scripts/ConvertUtf16ToUtf8.py 
> > > b/BaseTools/Scripts/ConvertUtf16ToUtf8.py
> > > new file mode 100755
> > > index 000..5f54603
> > > --- /dev/null
> > > +++ b/BaseTools/Scripts/ConvertUtf16ToUtf8.py
> > > @@ -0,0 +1,123 @@
> > > +## @file
> > > +#  Check a patch for various format issues
> > > +#
> > > +#  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
> > > +#
> > > +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > > +#  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> > > +#  EXPRESS OR IMPLIED.
> > > +#
> > > +
> > > +from __future__ import print_function
> > > +
> > > +Versio

Re: [edk2] MdeModulePkg: DebugAssert enhancement

[Kinney, Michael D]

Baranee,

I also think the following line could be changed for smaller code gen from:

+  ModuleNameSize   = AsciiStrLen("[") + AsciiStrLen (gEfiCallerBaseName) + 
AsciiStrLen("] ");

To:

+  //
+  // Compute string size of module name enclosed by []
+  //
+  ModuleNameSize   = 2 + AsciiStrSize (gEfiCallerBaseName);

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
> Liming
> Sent: Wednesday, December 2, 2015 6:07 PM
> To: Anbazhagan, Baraneedharan ; edk2-devel@lists.01.org
> Subject: Re: [edk2] MdeModulePkg: DebugAssert enhancement
> 
> Baranee:
>   Could you use CopyMem() to fill gEfiCallerBaseName instead of 
> AsciiSPrint()? This library instance is for size optimization. So, it uses
> CopyMem() to fill FileName and Description.
> 
> Thanks
> Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Anbazhagan, Baraneedharan
> Sent: Wednesday, December 02, 2015 11:42 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] MdeModulePkg: DebugAssert enhancement
> 
> If the assert happens in a library, then it's hard to determine which module 
> using that library is generating that assert.
> Use gEfiCallerBaseName in DebugAssert to display the module name.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Baraneedharan Anbazhagan 
> ---
>  .../PeiDxeDebugLibReportStatusCode/DebugLib.c  | 58 
> ++
>  .../PeiDxeDebugLibReportStatusCode.inf |  1 +
>  2 files changed, 39 insertions(+), 20 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> index f1d9827..af369ea 100644
> --- a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> +++ b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> @@ -22,6 +22,7 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include   #include  @@ 
> -261,6 +262,7 @@ DebugAssert (
>UINTN  HeaderSize;
>UINTN  TotalSize;
>CHAR8  *Temp;
> +  UINTN  ModuleNameSize;
>UINTN  FileNameSize;
>UINTN  DescriptionSize;
> 
> @@ -268,31 +270,37 @@ DebugAssert (
>// Get string size
>//
>HeaderSize   = sizeof (EFI_DEBUG_ASSERT_DATA);
> +  ModuleNameSize   = AsciiStrLen("[") + AsciiStrLen (gEfiCallerBaseName) + 
> AsciiStrLen("] ");
>FileNameSize = AsciiStrSize (FileName);
>DescriptionSize  = AsciiStrSize (Description);
> 
>//
>// Make sure it will all fit in the passed in buffer.
>//
> -  if (HeaderSize + FileNameSize + DescriptionSize > sizeof (Buffer)) {
> +  if (HeaderSize + ModuleNameSize + FileNameSize + DescriptionSize >
> + sizeof (Buffer)) {
>  //
> -// FileName + Description is too long to be filled into buffer.
> +// remove module name if it's too long to be filled into buffer
>  //
> -if (HeaderSize + FileNameSize < sizeof (Buffer)) {
> +ModuleNameSize = 0;
> +if (HeaderSize + FileNameSize + DescriptionSize > sizeof (Buffer))
> + {
>//
> -  // Description has enough buffer to be truncated.
> +  // FileName + Description is too long to be filled into buffer.
>//
> -  DescriptionSize = sizeof (Buffer) - HeaderSize - FileNameSize;
> -} else {
> -  //
> -  // FileName is too long to be filled into buffer.
> -  // FileName will be truncated. Reserved one byte for Description NULL 
> terminator.
> -  //
> -  DescriptionSize = 1;
> -  FileNameSize= sizeof (Buffer) - HeaderSize - DescriptionSize;
> +  if (HeaderSize + FileNameSize < sizeof (Buffer)) {
> +//
> +// Description has enough buffer to be truncated.
> +//
> +DescriptionSize = sizeof (Buffer) - HeaderSize - FileNameSize;
> +  } else {
> +//
> +// FileName is too long to be filled into buffer.
> +// FileName will be truncated. Reserved one byte for Description 
> NULL terminator.
> +//
> +DescriptionSize = 1;
> +FileNameSize= sizeof (Buffer) - HeaderSize - DescriptionSize;
> +  }
>  }
>}
> -
>//
>// Fill in EFI_DEBUG_ASSERT_DATA
>//
> @@ -300,17 +308,27 @@ DebugAssert (
>AssertData->LineNumber = (UINT32)LineNumber;
>TotalSize  = sizeof (EFI_DEBUG_ASSERT_DATA);
> 
> -  //
> -  // Copy Ascii FileName including NULL terminator.
> -  //
> -  Temp = CopyMem (AssertData + 1, FileName, FileNameSize);
> -  Temp[FileNameSize - 1] = 0;
> -  TotalSize += FileNameSize;
> +  Temp = (CHAR8 *)(AssertData + 1);
> +  if (ModuleNameSize != 0) {
> +//
> +// Copy Ascii ModuleName & FileName including NULL terminator
> +//
> +AsciiSPrint(Temp, ModuleNameSize + FileNameSize, "[%a] %a", 
> gEfiCallerBaseName, FileName);
> +

Re: [edk2] [Patch V4] ShellPkg/mm: Fix mm to support multiple root bridge platform

[Kinney, Michael D]

Ray,

Looks good.

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

Mike


> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, December 8, 2015 10:45 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Subject: [Patch V4] ShellPkg/mm: Fix mm to support multiple root bridge 
> platform
> 
> In multiple root bridge platforms, different root bridges may
> share the same segment but occupy different range of buses,
> or may occupy different segments.
> The fix is to find the correct root bridge IO instance by
> comparing not only the segment but also the bus ranges.
> It tries to access the MMIO and IO in the following order:
> PciRootBridgeIo, CpuIo and direct IO.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Michael.D.Kinney <michael.d.kin...@intel.com>
> ---
>  ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c   | 917 
> ++---
>  .../UefiShellDebug1CommandsLib.h   |   3 +-
>  .../UefiShellDebug1CommandsLib.inf |   4 +-
>  .../UefiShellDebug1CommandsLib.uni | Bin 139696 -> 139230 
> bytes
>  ShellPkg/ShellPkg.dsc  |   1 +
>  5 files changed, 464 insertions(+), 461 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c 
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c
> index ca64f2c..2f22629 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c
> @@ -2,7 +2,7 @@
>Main file for Mm shell Debug1 function.
> 
>(C) Copyright 2015 Hewlett-Packard Development Company, L.P.
> -  Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
> +  Copyright (c) 2005 - 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
> @@ -15,16 +15,25 @@
> 
>  #include "UefiShellDebug1CommandsLib.h"
>  #include 
> +#include 
>  #include 
>  #include 
> 
>  typedef enum {
> -  EfiMemory,
> -  EFIMemoryMappedIo,
> -  EfiIo,
> -  EfiPciConfig,
> -  EfiPciEConfig
> -} EFI_ACCESS_TYPE;
> +  ShellMmMemory,
> +  ShellMmMemoryMappedIo,
> +  ShellMmIo,
> +  ShellMmPci,
> +  ShellMmPciExpress
> +} SHELL_MM_ACCESS_TYPE;
> +
> +CONST UINT16 mShellMmAccessTypeStr[] = {
> +  STRING_TOKEN (STR_MM_MEM),
> +  STRING_TOKEN (STR_MM_MMIO),
> +  STRING_TOKEN (STR_MM_IO),
> +  STRING_TOKEN (STR_MM_PCI),
> +  STRING_TOKEN (STR_MM_PCIE)
> +};
> 
>  STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
>{L"-mmio", TypeFlag},
> @@ -37,161 +46,341 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
>{NULL, TypeMax}
>};
> 
> -STATIC CONST UINT64 MaxNum[9]  = { 0xff, 0x, 0x, 
> 0xULL };
> +CONST UINT64 mShellMmMaxNumber[] = {
> +  0, MAX_UINT8, MAX_UINT16, 0, MAX_UINT32, 0, 0, 0, MAX_UINT64
> +};
> +CONST EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_WIDTH mShellMmRootBridgeIoWidth[] = {
> +  0, EfiPciWidthUint8, EfiPciWidthUint16, 0, EfiPciWidthUint32, 0, 0, 0, 
> EfiPciWidthUint64
> +};
> +CONST EFI_CPU_IO_PROTOCOL_WIDTH mShellMmCpuIoWidth[] = {
> +  0, EfiCpuIoWidthUint8, EfiCpuIoWidthUint16, 0, EfiCpuIoWidthUint32, 0, 0, 
> 0, EfiCpuIoWidthUint64
> +};
> 
>  /**
> -  Read some data into a buffer from memory.
> -
> -  @param[in] WidthThe width of each read.
> -  @param[in] Addresss The memory location to start reading at.
> -  @param[in] Size The size of Buffer in Width sized units.
> -  @param[out] Buffer  The buffer to read into.
> +  Extract the PCI segment, bus, device, function, register from
> +  from a SHELL_MM_PCI or SHELL_MM_PCIE format of address..
> +
> +  @param[in]  PciFormat  Whether the address is of PCI format of PCIE 
> format.
> +  @param[in]  AddressSHELL_MM_PCI or SHELL_MM_PCIE address.
> +  @param[out] SegmentPCI segment number.
> +  @param[out] BusPCI bus number.
> +  @param[out] Device PCI device number.
> +  @param[out] Function   PCI function number.
> +  @param[out] Register   PCI register offset.
>  **/
>  VOID
>  EFIAPI
> -ReadMem (
> -  IN  EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_WIDTH  Width,
> -  IN  UINT64Address,
> -  IN  UINTN Size,
> -  OUT VOID  *Buffer
> +ShellMmDecodePciAddress (
> +  IN BOOLEANPciFormat,
&g

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

[Kinney, Michael D]

Ray,

Do you prefer PCD solution?

Mike

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, December 9, 2015 4:45 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek 
> <ler...@redhat.com>
> Cc: Paolo Bonzini <pbonz...@redhat.com>; Scott Duplichan <sc...@notabs.org>; 
> edk2-devel@lists.01.org <edk2-de...@ml01.01.org>;
> Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang 
> issue
> 
> Mike,
> The UEFI Spec doesn't require implementation to call 
> InstallConfigurationTable() every time the ACPI table is updated through
> EFI_ACPI_PROTOCOL.InstallAcpiTable().
> I checked the implementation:
> AcpiSupportDxe in IntelFrameworkModulePkg only calls 
> IntallConfigurationTable() in the first time InstallAcpiTable() is called.
> AcpiTableDxe in MdeModulePkg calls InstallConfigurationTable() every time 
> InstallAcpiTable() is called.
> 
> So we cannot depend on the event notification for EFI_ACPI_TABLE_GUID.
> 
> PI Spec defines a ACPI_SDT protocol (produced by AcpiTableDxe in 
> MdeModulePkg) which supports table installation notification. But
> it's an optional protocol and
> not every platform includes AcpiTableDxe to produce this protocol.
> Per my understanding, only EFI_ACPI_PROTOCOL is mandatory.
> 
> Regards,
> Ray
> 
> 
> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, December 10, 2015 3:49 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Cc: Paolo Bonzini <pbonz...@redhat.com>; Scott Duplichan <sc...@notabs.org>; 
> edk2-devel@lists.01.org <edk2-de...@ml01.01.org>;
> Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang 
> issue
> 
> Ray,
> 
> The UEFI Specification 2.5 p. 136 - CreateEventEx() requires an event group 
> to be signaled every time a configuration table is installed
> or updated.
> 
> The RTC driver could create an event notification for the EFI_ACPI_TABLE_GUID 
> and cache FADT field in notification function.
> 
> Mike
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Wednesday, December 9, 2015 10:48 AM
> > To: Laszlo Ersek <ler...@redhat.com>
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Paolo Bonzini 
> > <pbonz...@redhat.com>; Scott Duplichan <sc...@notabs.org>;
> > edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Zeng, Star 
> > <star.z...@intel.com>
> > Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang 
> > issue
> >
> > Laszlo,
> > I agree with your concerns that the ACPI table can be modified at anytime 
> > before firmware hands off control to OS, after all it's a
> > buffer reported by system configuration table. So in extreme cases, a 
> > platform may firstly set FADT.century to 0x80 but change it to
> > 0x32 later. If the SetTime isn't called later, century won't be saved to 
> > CMOS. Even RTC driver hooks the ExitBootServices event to
> > update CMOS, the FADT.century may be changed after RTC's callback.
> >
> > So how about use a PCD named PcdCmosCenturyLocation type UINT8, and the PCD 
> > value should less then 0x80 otherwise assertion
> in
> > RTC driver happens?
> > It's platform 's responsibility to convert 0 to 0x80 and save in ACPI table 
> > if it's a win-only platform. For a OS neutral platform, non-
> zero
> > PCD should be always chosen.
> >
> >
> >
> > Thanks,
> > Ray
> >
> > > 在 2015年12月10日，02:07，Laszlo Ersek <ler...@redhat.com> 写道：
> > >
> > >> On 12/09/15 18:55, Kinney, Michael D wrote:
> > >> I think we need to evaluate both methods discussed here:
> > >>
> > >> 1) RTC driver use info from FADT in SetTime() when FADT is available.  
> > >> Add event notification to RTC driver to capture FADT info
> > before ExitBootServices().
> > >> 2) Use PCD in RTC driver and in ACPI FADT table.
> > >>
> > >> Advantage of (1) is that it is compatible with existing ACPI Table 
> > >> implementations.
> > >
> > > I agree that (1) is compatible with existing *valid* ACPI table
> > > implementations.
> > >
> > > I can't resist mentioning though that I've seen platform firmware "in
> > > the wild" that messed with ACPI tables in the exit-boot-services
> > > callback. Obviously this is completely broke

Re: [edk2] [Patch] MdeModulePkg: Add PciSioSerialDxe driver

[Kinney, Michael D]

Ray,

This looks good.  I tested the baud rate check and calculations.

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

Mike

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, December 9, 2015 6:21 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Tian, Feng <feng.t...@intel.com>; Kinney, 
> Michael D <michael.d.kin...@intel.com>
> Subject: [Patch] MdeModulePkg: Add PciSioSerialDxe driver
> 
> PciSioSerialDxe driver can manages UARTs on a SIO chip or a PCI/PCIE
> card.
> It manages the SIO instance whose last device path node is a ACPI
> device path and the HID in the ACPI device path node equals to
> EISA_PNP_ID (0x501).
> It also manages the PCI IO instance whose class code is 7/0/2 (16550
> UART). But when proper value is set to PcdPciSerialParameters, the
> driver can also manage non-standard PCI serial cards by matching
> the Vendor ID and Device ID specified in PcdPciSerialParameters.
> The PCI BAR index, IO/MMIO offset, register stride, clock rate can
> also be specified through the same PCD.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> ---
>  .../Bus/Pci/PciSioSerialDxe/ComponentName.c|  288 +
>  .../Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf|   81 ++
>  .../Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.uni|  Bin 0 -> 1940 bytes
>  .../Pci/PciSioSerialDxe/PciSioSerialDxeExtra.uni   |  Bin 0 -> 1380 bytes
>  MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c  | 1243 ++
>  MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.h  |  789 
>  MdeModulePkg/Bus/Pci/PciSioSerialDxe/SerialIo.c| 1321 
> 
>  MdeModulePkg/MdeModulePkg.dec  |   38 +
>  MdeModulePkg/MdeModulePkg.dsc  |1 +
>  9 files changed, 3761 insertions(+)
>  create mode 100644 MdeModulePkg/Bus/Pci/PciSioSerialDxe/ComponentName.c
>  create mode 100644 MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
>  create mode 100644 MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.uni
>  create mode 100644 
> MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxeExtra.uni
>  create mode 100644 MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
>  create mode 100644 MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.h
>  create mode 100644 MdeModulePkg/Bus/Pci/PciSioSerialDxe/SerialIo.c
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/ComponentName.c
> b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/ComponentName.c
> new file mode 100644
> index 000..994dc84
> --- /dev/null
> +++ b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/ComponentName.c
> @@ -0,0 +1,288 @@
> +/** @file
> +  UEFI Component Name and Name2 protocol for Isa serial driver.
> +
> +Copyright (c) 2006 - 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
> +
> +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 "Serial.h"
> +
> +//
> +// EFI Component Name Protocol
> +//
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL  
> gPciSioSerialComponentName = {
> +  SerialComponentNameGetDriverName,
> +  SerialComponentNameGetControllerName,
> +  "eng"
> +};
> +
> +//
> +// EFI Component Name 2 Protocol
> +//
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL 
> gPciSioSerialComponentName2 = {
> +  (EFI_COMPONENT_NAME2_GET_DRIVER_NAME) SerialComponentNameGetDriverName,
> +  (EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME) 
> SerialComponentNameGetControllerName,
> +  "en"
> +};
> +
> +
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE 
> mSerialDriverNameTable[] = {
> +  {
> +"eng;en",
> +L"PCI SIO Serial Driver"
> +  },
> +  {
> +NULL,
> +NULL
> +  }
> +};
> +
> +GLOBAL_REMOVE_IF_UNREFERENCED CHAR16 mSioSerialPortName[] = L"SIO Serial 
> Port #%d";
> +GLOBAL_REMOVE_IF_UNREFERENCED CHAR16 mPciSerialPortName[] = L"PCI Serial 
> Port #%d";
> +
> +/**
> +  Retrieves a Unicode string that is the user readable name of the driver.
> +
> +  This function retrieves the user readable nam

Re: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg packages

[Kinney, Michael D]

Jordan,

Reponses included below.

1) edk2: Maintainers.txt patch email sent.
2) Thank you very much for ack and detailed review/feedback in Quark*Pkgs
3) I have fixed all the items for the edk2-non-osi repository and pushed them 
to:
 
https://github.com/mdkinney/edk2-non-osi.git

Can you create the new edk2-non-osi repository on tianocore and import this 
content?

Thanks,

Mike


> -Original Message-
> From: Justen, Jordan L
> Sent: Monday, December 14, 2015 11:47 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-
> de...@lists.01.org (edk2-devel@lists.01.org)  de...@lists.01.org>
> Subject: RE: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg
> packages
> 
> On 2015-12-13 14:48:54, Kinney, Michael D wrote:
> > Jordan,
> >
> > I have updated to Quark_V3 that uses this concept along with a
> > proposed edk2-non-osi repository with a new QuarkSocBinPkg. It
> uses
> > PACKAGES_PATH to support the multiple repositories to do a
> build.
> > The content is posted for review on GitHub.
> >
> > The QuarkSocPkg and QuarkPlatformPkg are in branch Quark_V3 on
> GitHub at:
> >
> > https://github.com/mdkinney/edk2.git
> >
> > The edk2-non-iso repository with the QuarkSocBinPkg is on
> GitHub at:
> >
> > https://github.com/mdkinney/edk2-non-osi.git
> >
> > Here are the instructions I use to clone the content and set
> > environment variables to perform platform builds.
> >
> >
> 
> ==
> > git clone https://github.com/mdkinney/edk2.git --branch
> Quark_V3
> 
> I notice that this file doesn't have the standard copyright
> header:
> 
> QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLibModStrs.un
> i
> 
> I found this with:
> 
> $ git grep -L 'http://opensource.org/licenses/bsd-license.php'
> Quark*
> 

Thanks.  I have fixed this.

> Also, QuarkPlatformPkg/License.txt and QuarkSocPkg/License.txt
> are
> using unix line endings. How about copying MdePkg/License.txt
> directly?
> 
> I found this with:
> 
> $ md5sum */License.txt
> 

I found these 2 license files yesterday with wrong line endings.  I have fixed 
them.
I also found a C source file with a Unicode '-' character in it, and I fixed 
that too.

> With these fixed:
> 
> Acked-by: Jordan Justen <jordan.l.jus...@intel.com>
> 
> So, I guess these probably two changes are ready to commit,
> right?

Thank you very much for the detailed reviews and feedback.
Yes.  I am ready to commit these two packages.

> 
> * QuarkPlatformPkg: Add new package for Galileo boards
> * QuarkSocPkg: Add new package for Quark SoC X1000
> 
> Can you send out a patch for the Maintainers.txt?

Yes.  I have sent patch review email.

> 
> > git clone https://github.com/tianocore/edk2-FatPkg.git FatPkg
> > git clone https://github.com/mdkinney/edk2-non-osi.git
> 
> I also reviewed the updated edk2-non-osi tree with
> 5573e513dfb88f96c8ae08471e369c335a540a37 "QuarkSocBinPkg:
> Reformat
> IntelProprietaryLicense.txt". I think you should just squash
> that into
> the previous commit.

Done

> 
> Also, in:
> 
> In QuarkSocBinPkg/License.txt
> 
> You have this text:
> 
> > Additional terms:
> > -
> >
> QuarkSocBinPkg\QuarkNorthCluster\Binary\QuarkMicrocode\IntelProp
> rietaryLicense.txt
> 
> This sounds similar to the FAT driver, where all of the content
> has
> BSD + and additional term. But, in this case, the license only
> applies
> to 1 file. How about something like what we have in
> OvmfPkg/License.txt? For example:
> 
> > Some files are subject to a license documented in the
> > IntelProprietaryLicense.txt file. These files are in the same
> > directory as IntelProprietaryLicense.txt, and they do not have
> a
> > license specified within the file.

Done

> 
> -Jordan
> 
> > git clone https://github.com/tianocore/edk2-BaseTools-
> win32.git
> >
> > set WORKSPACE=%CD%
> > set PACKAGES_PATH=%WORKSPACE%\edk2;%WORKSPACE%\edk2-non-osi
> > set EDK_TOOLS_BIN=%WORKSPACE%\edk2-BaseTools-win32
> >
> > cd edk2
> >
> > edkSetup.bat
> >
> > build -a IA32 -t VS2015x86 -p QuarkPlatformPkg/Quark.dsc
> > build -a IA32 -t VS2015x86 -p QuarkPlatformPkg/QuarkMin.dsc
> >
> 
> =
> >
> > commit 613f0f5ff082d85e02403eddefdc1d54138663c5
> > Author: Michael Kinney <michael.d.kin...@intel.com>
> > Date:   Tue Nov 24 23:43:40 2015 -0800
> >
> > QuarkPlatformPkg: Add new pa

Re: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is detected

[Kinney, Michael D]

Samer,

Yes.  Thank you!

Mike

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
Sent: Wednesday, December 16, 2015 8:59 AM
To: patrick.ma...@caviumnetworks.com; edk2-devel@lists.01.org; Kinney, Michael 
D <michael.d.kin...@intel.com>
Cc: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>
Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is 
detected

Mike,

If you would like to avoid introducing the new PCD, I am fine with looking at 
the Option ROM BAR and degrade only if there is a legacy option ROM. Would you 
like me to submit a new patch that does that?

Thanks,
--Samer


-Original Message-
From: Kinney, Michael D [michael.d.kin...@intel.com]
Received: Tuesday, 15 Dec 2015, 6:54PM
To: El-Haj-Mahmoud, Samer [samer.el-haj-mahm...@hpe.com]; Mahan, Patrick 
[patrick.ma...@caviumnetworks.com]; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> 
[edk2-devel@lists.01.org]; Kinney, Michael D [michael.d.kin...@intel.com]
Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is 
detected
Samer,

Do you think it makes sense to add code to check to see if legacy option ROM 
image is present in the option ROM BAR and only degrade if that type of image 
is found.

That could avoid the introduction of a new PCD.

Thanks,

Mike

> -Original Message-
> From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-
> mahm...@hpe.com<mailto:mahm...@hpe.com>]
> Sent: Tuesday, December 15, 2015 10:31 AM
> To: Mahan, Patrick 
> <patrick.ma...@caviumnetworks.com<mailto:patrick.ma...@caviumnetworks.com>>; 
> edk2-
> de...@lists.01.org<mailto:de...@lists.01.org>; Kinney, Michael D
> <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
> Cc: El-Haj-Mahmoud, Samer 
> <samer.el-haj-mahm...@hpe.com<mailto:samer.el-haj-mahm...@hpe.com>>
> Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when
> an option ROM is detected
>
> Patrick,
> The Patch was submitted to EDK2 list yesterday. Look for subject
> line:
>
> [PATCH] MdePkg: Add PcdPciDegradeIfOptionRomPresent PCD for PCI
> resource degradation policy
>
> Please review.
>
>  I also CC'd Mike Kinney on the review.
>
> Thanks,
> --Samer
>
>
> -Original Message-
> From: Mahan, Patrick [mailto:patrick.ma...@caviumnetworks.com]
> Sent: Tuesday, December 15, 2015 12:27 PM
> To: El-Haj-Mahmoud, Samer 
> <samer.el-haj-mahm...@hpe.com<mailto:samer.el-haj-mahm...@hpe.com>>; edk2-
> de...@lists.01.org<mailto:de...@lists.01.org>
> Subject: Re: [edk2] Regarding the demotion of 64-bit BARs when
> an option ROM is detected
>
> Greetings Samer,
>
> I would like to see this patch implemented.  Part of the issue I
> am wrestling with on our AARCH64 platform is how our PCIe's are
> supported.  In our current architecture, we can have up to 6
> PCIe's connected through two Switch Logic Interfaces (SLI) that
> must be programmed correctly.  Part of this is the BAR address
> that is in use which depends heavily on the BAR type.  What we
> are seeing is that the BAR type is being demoted to 32-bit which
> causes us to program the SLI for 32-bit access.  But the PCIe
> device is 64-bit and attempts to use 64-bit addressing which
> fails.
>
> A PCD that can be configured to disable the demotion based on
> the presence of an option ROM would be greatly appreciated.
> Then the code in DegradeResource() could simply check to see if
> it needed to enforce this demotion or not.
>
> I can understand if this were a legacy BIOS image as this
> currently seems (to me) to limit option ROM drivers to be 32-bit
> only.
>
> As I stated below, I currently have it commented out and this is
> allowing our SLI's to be programmed correctly.
>
> I'll be glad to review the patch when you have it ready.
>
> Thanks,
>
> Patrick
>
> 
> From: El-Haj-Mahmoud, Samer 
> <samer.el-haj-mahm...@hpe.com<mailto:samer.el-haj-mahm...@hpe.com>>
> Sent: Monday, December 14, 2015 3:35 PM
> To: Mahan, Patrick; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: El-Haj-Mahmoud, Samer
> Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when
> an option ROM is detected
>
> Hello Patrick,
>
> We ran into the same issue of automatic demoation simply because
> of the presence of an OptionROM. We believe this is an overly
> aggressive policy. In fact, I have a patch that I am about to
> submit that adds a platform PCD to enable/disable this policy.
>
> Would like feedback on the idea as well as the patch.
>
> Thanks,
> --Samer
>
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@list

Re: [edk2] [Patch] MdePkg: Convert IoLibEbc.c source file to DOS format

[Kinney, Michael D]

Liming,

Thanks for fixing this.

Reviewed-by: Michael Kinney 

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Liming Gao
> Sent: Wednesday, December 16, 2015 11:22 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch] MdePkg: Convert IoLibEbc.c source file
> to DOS format
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibEbc.c | 342
> +--
>  1 file changed, 171 insertions(+), 171 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/IoLibEbc.c
> b/MdePkg/Library/BaseIoLibIntrinsic/IoLibEbc.c
> index 991c1e0..e12a5ae 100644
> --- a/MdePkg/Library/BaseIoLibIntrinsic/IoLibEbc.c
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/IoLibEbc.c
> @@ -1,171 +1,171 @@
> -/** @file
> -  I/O Library for EBC.
> -
> -  EBC does not support port I/O.  All APIs in this file
> ASSERT().
> -
> -  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.
> -
> -  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 "BaseIoLibIntrinsicInternal.h"
> -
> -/**
> -  Reads an 8-bit I/O port.
> -
> -  Reads the 8-bit I/O port specified by Port. The 8-bit read
> value is returned.
> -  This function must guarantee that all I/O read and write
> operations are
> -  serialized.
> -
> -  If 8-bit I/O port operations are not supported, then
> ASSERT().
> -
> -  @param  Port  The I/O port to read.
> -
> -  @return The value read.
> -
> -**/
> -UINT8
> -EFIAPI
> -IoRead8 (
> -  IN  UINTN Port
> -  )
> -{
> -  ASSERT (FALSE);
> -  return 0;
> -}
> -
> -/**
> -  Writes an 8-bit I/O port.
> -
> -  Writes the 8-bit I/O port specified by Port with the value
> specified by Value
> -  and returns Value. This function must guarantee that all I/O
> read and write
> -  operations are serialized.
> -
> -  If 8-bit I/O port operations are not supported, then
> ASSERT().
> -
> -  @param  Port  The I/O port to write.
> -  @param  Value The value to write to the I/O port.
> -
> -  @return The value written to the I/O port.
> -
> -**/
> -UINT8
> -EFIAPI
> -IoWrite8 (
> -  IN  UINTN Port,
> -  IN  UINT8 Value
> -  )
> -{
> -  ASSERT (FALSE);
> -  return 0;
> -}
> -
> -/**
> -  Reads a 16-bit I/O port.
> -
> -  Reads the 16-bit I/O port specified by Port. The 16-bit read
> value is returned.
> -  This function must guarantee that all I/O read and write
> operations are
> -  serialized.
> -
> -  If 16-bit I/O port operations are not supported, then
> ASSERT().
> -  If Port is not aligned on a 16-bit boundary, then ASSERT().
> -
> -  @param  Port  The I/O port to read.
> -
> -  @return The value read.
> -
> -**/
> -UINT16
> -EFIAPI
> -IoRead16 (
> -  IN  UINTN Port
> -  )
> -{
> -  ASSERT (FALSE);
> -  return 0;
> -}
> -
> -/**
> -  Writes a 16-bit I/O port.
> -
> -  Writes the 16-bit I/O port specified by Port with the value
> specified by Value
> -  and returns Value. This function must guarantee that all I/O
> read and write
> -  operations are serialized.
> -
> -  If 16-bit I/O port operations are not supported, then
> ASSERT().
> -  If Port is not aligned on a 16-bit boundary, then ASSERT().
> -
> -  @param  Port  The I/O port to write.
> -  @param  Value The value to write to the I/O port.
> -
> -  @return The value written to the I/O port.
> -
> -**/
> -UINT16
> -EFIAPI
> -IoWrite16 (
> -  IN  UINTN Port,
> -  IN  UINT16Value
> -  )
> -{
> -  ASSERT (FALSE);
> -  return 0;
> -}
> -
> -/**
> -  Reads a 32-bit I/O port.
> -
> -  Reads the 32-bit I/O port specified by Port. The 32-bit read
> value is returned.
> -  This function must guarantee that all I/O read and write
> operations are
> -  serialized.
> -
> -  If 32-bit I/O port operations are not supported, then
> ASSERT().
> -  If Port is not aligned on a 32-bit boundary, then ASSERT().
> -
> -  @param  Port  The I/O port to read.
> -
> -  @return The value read.
> -
> -**/
> -UINT32
> -EFIAPI
> -IoRead32 (
> -  IN  UINTN Port
> -  )
> -{
> -  ASSERT (FALSE);
> -  return 0;
> -}
> -
> -/**
> -  Writes a 32-bit I/O port.
> -
> -  Writes the 32-bit I/O port specified by Port with the value
> specified by Value
> -  and returns Value. This function must guarantee that all I/O
> read and write
> -  operations are serialized.
> -
> -  If 32-bit I/O port operations are not supported, then
> ASSERT().
> -  

Re: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg packages

[Kinney, Michael D]

QuarkSocPkg committed as SVN r19286 
QuarkPlatformPkg committed as SVN r19287

> -Original Message-
> From: Justen, Jordan L
> Sent: Tuesday, December 15, 2015 11:30 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-
> de...@lists.01.org (edk2-devel@lists.01.org)  de...@lists.01.org>
> Subject: RE: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg
> packages
> 
> On 2015-12-15 09:54:25, Kinney, Michael D wrote:
> > Jordan,
> >
> > Reponses included below.
> >
> > 1) edk2: Maintainers.txt patch email sent.
> > 2) Thank you very much for ack and detailed review/feedback in
> Quark*Pkgs
> > 3) I have fixed all the items for the edk2-non-osi repository
> and pushed them to:
> >
> > https://github.com/mdkinney/edk2-non-osi.git
> >
> > Can you create the new edk2-non-osi repository on
> tianocore and
> > import this content?
> >
> 
> I pushed your branch to:
> 
> https://github.com/tianocore/edk2-non-osi
> 
> I guess this is our first repo where the upstream is git rather
> than
> svn...
> 
> -Jordan
> 
> >
> > > -Original Message-
> > > From: Justen, Jordan L
> > > Sent: Monday, December 14, 2015 11:47 PM
> > > To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-
> > > de...@lists.01.org (edk2-devel@lists.01.org)  > > de...@lists.01.org>
> > > Subject: RE: [edk2] [PATCH] Add QuarkSocPkg and
> QuarkPlatformPkg
> > > packages
> > >
> > > On 2015-12-13 14:48:54, Kinney, Michael D wrote:
> > > > Jordan,
> > > >
> > > > I have updated to Quark_V3 that uses this concept along
> with a
> > > > proposed edk2-non-osi repository with a new
> QuarkSocBinPkg. It
> > > uses
> > > > PACKAGES_PATH to support the multiple repositories to do a
> > > build.
> > > > The content is posted for review on GitHub.
> > > >
> > > > The QuarkSocPkg and QuarkPlatformPkg are in branch
> Quark_V3 on
> > > GitHub at:
> > > >
> > > > https://github.com/mdkinney/edk2.git
> > > >
> > > > The edk2-non-iso repository with the QuarkSocBinPkg is on
> > > GitHub at:
> > > >
> > > > https://github.com/mdkinney/edk2-non-osi.git
> > > >
> > > > Here are the instructions I use to clone the content and
> set
> > > > environment variables to perform platform builds.
> > > >
> > > >
> > >
> 
> > > ==
> > > > git clone https://github.com/mdkinney/edk2.git --branch
> > > Quark_V3
> > >
> > > I notice that this file doesn't have the standard copyright
> > > header:
> > >
> > >
> QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLibModStrs.un
> > > i
> > >
> > > I found this with:
> > >
> > > $ git grep -L 'http://opensource.org/licenses/bsd-
> license.php'
> > > Quark*
> > >
> >
> > Thanks.  I have fixed this.
> >
> > > Also, QuarkPlatformPkg/License.txt and
> QuarkSocPkg/License.txt
> > > are
> > > using unix line endings. How about copying
> MdePkg/License.txt
> > > directly?
> > >
> > > I found this with:
> > >
> > > $ md5sum */License.txt
> > >
> >
> > I found these 2 license files yesterday with wrong line
> endings.  I have fixed them.
> > I also found a C source file with a Unicode '-' character in
> it, and I fixed that too.
> >
> > > With these fixed:
> > >
> > > Acked-by: Jordan Justen <jordan.l.jus...@intel.com>
> > >
> > > So, I guess these probably two changes are ready to commit,
> > > right?
> >
> > Thank you very much for the detailed reviews and feedback.
> > Yes.  I am ready to commit these two packages.
> >
> > >
> > > * QuarkPlatformPkg: Add new package for Galileo boards
> > > * QuarkSocPkg: Add new package for Quark SoC X1000
> > >
> > > Can you send out a patch for the Maintainers.txt?
> >
> > Yes.  I have sent patch review email.
> >
> > >
> > > > git clone https://github.com/tianocore/edk2-FatPkg.git
> FatPkg
> > > > git clone https://github.com/mdkinney/edk2-non-osi.git
> > >
> > > I also reviewed the updated edk2-non-osi tree with
> > > 5573e513dfb88f96c8ae08471e369c335a540a37 "

Re: [edk2] InsertImageRecord and Section Alignment

[Kinney, Michael D]

Baranee,

What build flags are you using?

Most platforms can add the following in their DSC file to get this to work form 
VS20xx tool chains.

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
  MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Anbazhagan, Baraneedharan
> Sent: Tuesday, December 15, 2015 8:31 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Yao, Jiewen
> <jiewen@intel.com>; Laszlo Ersek <ler...@redhat.com>
> Cc: Hamel, Lee M <lee.m.ha...@intel.com>; Barlow, Dallas
> <dallas.bar...@hp.com>; edk2-devel@lists.01.org  de...@ml01.01.org>
> Subject: Re: [edk2] InsertImageRecord and Section Alignment
> 
> Hi,
> When I tried to enable section alignment in DSC for Runtime
> modules, am getting a build error that section alignment and
> file alignment doesn't match(GenFvInternalLib.c). Am using
> VS2012x86 build tools. Whether any other build flag needs to be
> set?
> 
> - Baranee
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Kinney,
> > Michael D
> > Sent: Monday, December 07, 2015 8:23 PM
> > To: Yao, Jiewen; Laszlo Ersek; Kinney, Michael D
> > Cc: Hamel, Lee M; edk2-devel@lists.01.org
> > Subject: Re: [edk2] InsertImageRecord and Section Alignment
> >
> > Jiewen,
> >
> > I agree that is a good place to put the error message.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Yao, Jiewen
> > > Sent: Sunday, December 6, 2015 7:06 PM
> > > To: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo
> Ersek
> > > <ler...@redhat.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>
> > > Cc: Hamel, Lee M <lee.m.ha...@intel.com>; edk2-
> de...@lists.01.org
> > > <edk2-de...@ml01.01.org>
> > > Subject: RE: [edk2] InsertImageRecord and Section Alignment
> > >
> > > Hi Mike
> > > I agree that we can change this from ERROR to WARNING, and
> only add 1 ERROR
> > message.
> > >
> > > However, the
> \MdeModulePkg\Universal\PropertiesTableAttributesDxe
> > > module is optional module, because a platform may use its
> own module to set
> > attributes for ACPINvs or reserved.
> > >
> > > How about we add error message when install this table in
> > DxeCore.InstallPropertiesTable().
> > > if ((mPropertiesTable.MemoryProtectionAttribute &
> > >
> EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA)
> ==
> > 0) {
> > >   DEBUG ((EFI_D_ERROR, "MemoryProtectionAttribute
> > NON_EXECUTABLE_PE_DATA  not set\n")); <== New line
> > >   return ;
> > > }
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of
> > > Kinney, Michael D
> > > Sent: Friday, December 04, 2015 8:27 AM
> > > To: Laszlo Ersek; Kinney, Michael D
> > > Cc: Hamel, Lee M; edk2-devel@lists.01.org
> > > Subject: Re: [edk2] InsertImageRecord and Section Alignment
> > >
> > > Laszlo,
> > >
> > > That is a good question.  If a platform requires
> > >
> EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA
> to
> > be set, then it is an error condition.  That is why it is an
> error message and not a
> > warning message.
> > >
> > > We could consider changing this specific message to a
> warning, and add
> > > one error message from the
> > > \MdeModulePkg\Universal\PropertiesTableAttributesDxe module.
> That way, only
> > platforms that include this module will get an error message
> if any runtime modules
> > for not use 4KB aligned.
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > > > Sent: Thursday, December 3, 2015 3:36 PM
> > > > To: Kinney, Michael D <michael.d.kin...@intel.com>
> > > > Cc: Hamel, Lee M <lee.m.ha...@intel.com>; edk2-
> de...@lists.01.org
> > > > <edk2-de...@ml01.01.org>
> > > > Subject: Re: [edk2] InsertImageRecord and Section
> Alignment
> > > >
> > > > On 12/03/15 21:16, Kinney, Michael D wrote:
> > > > > Lee,
> > > > >
> > > > > It is a feature from U

Re: [edk2] InsertImageRecord and Section Alignment

[Kinney, Michael D]

Baranee,

I see that error message if a PE/COFF image is stored in TE format or is XIP 
PE/COFF image.

In general, modules of type DXE_RUNTIME_DRIVER are not expected to use TE or be 
XIP.

Here is an example FDF file FFS rule for modules of type DXE_RUNTIME_DRIVER.  
It uses PE32 (not TE) and it does not strip the relocations.

[Rule.Common.DXE_RUNTIME_DRIVER]
  FILE DRIVER = $(NAMED_GUID) {
DXE_DEPEX DXE_DEPEX Optional   $(INF_OUTPUT)/$(MODULE_NAME).depex
PE32  PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
UISTRING="$(MODULE_NAME)" Optional
VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
  }

Are you using a different rule?

Mike



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Anbazhagan, Baraneedharan
> Sent: Tuesday, December 15, 2015 5:07 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; Yao, Jiewen
> <jiewen@intel.com>; Laszlo Ersek <ler...@redhat.com>
> Cc: Hamel, Lee M <lee.m.ha...@intel.com>; Barlow, Dallas
> <dallas.bar...@hp.com>; edk2-devel@lists.01.org  de...@ml01.01.org>
> Subject: Re: [edk2] InsertImageRecord and Section Alignment
> 
> Hi Mike,
> Am using the same build flag that you mentioned and getting the
> build error - 'Section-Alignment and File-Alignment do not match
> :.ffs'
> 
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> 
> Thanks,
> Baranee
> 
> > -Original Message-
> > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > Sent: Tuesday, December 15, 2015 6:57 PM
> > To: Anbazhagan, Baraneedharan <anbazha...@hp.com>; Yao, Jiewen
> > <jiewen@intel.com>; Laszlo Ersek <ler...@redhat.com>;
> Kinney, Michael D
> > <michael.d.kin...@intel.com>
> > Cc: Hamel, Lee M <lee.m.ha...@intel.com>; Barlow, Dallas
> > <dallas.bar...@hp.com>; edk2-devel@lists.01.org  de...@ml01.01.org>
> > Subject: RE: [edk2] InsertImageRecord and Section Alignment
> >
> > Baranee,
> >
> > What build flags are you using?
> >
> > Most platforms can add the following in their DSC file to get
> this to work form
> > VS20xx tool chains.
> >
> > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> >   MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of
> > > Anbazhagan, Baraneedharan
> > > Sent: Tuesday, December 15, 2015 8:31 AM
> > > To: Kinney, Michael D <michael.d.kin...@intel.com>; Yao,
> Jiewen
> > > <jiewen@intel.com>; Laszlo Ersek <ler...@redhat.com>
> > > Cc: Hamel, Lee M <lee.m.ha...@intel.com>; Barlow, Dallas
> > > <dallas.bar...@hp.com>; edk2-devel@lists.01.org  > > de...@ml01.01.org>
> > > Subject: Re: [edk2] InsertImageRecord and Section Alignment
> > >
> > > Hi,
> > > When I tried to enable section alignment in DSC for Runtime
> modules,
> > > am getting a build error that section alignment and file
> alignment
> > > doesn't match(GenFvInternalLib.c). Am using
> > > VS2012x86 build tools. Whether any other build flag needs to
> be set?
> > >
> > > - Baranee
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On
> > > Behalf Of Kinney,
> > > > Michael D
> > > > Sent: Monday, December 07, 2015 8:23 PM
> > > > To: Yao, Jiewen; Laszlo Ersek; Kinney, Michael D
> > > > Cc: Hamel, Lee M; edk2-devel@lists.01.org
> > > > Subject: Re: [edk2] InsertImageRecord and Section
> Alignment
> > > >
> > > > Jiewen,
> > > >
> > > > I agree that is a good place to put the error message.
> > > >
> > > > Mike
> > > >
> > > > > -Original Message-
> > > > > From: Yao, Jiewen
> > > > > Sent: Sunday, December 6, 2015 7:06 PM
> > > > > To: Kinney, Michael D <michael.d.kin...@intel.com>;
> Laszlo
> > > Ersek
> > > > > <ler...@redhat.com>; Kinney, Michael D
> > > <michael.d.kin...@intel.com>
> > > > > Cc: Hamel, Lee M <lee.m.ha...@intel.com>; edk2-
> > > de...@lists.01.org
> > > > > <edk2-de...@ml01.01.org>
> > > > > Subject: RE: [edk2] InsertImageRecord and Section
&g

Re: [edk2] [PATCH v2 00/20] Convert utf-16 .uni files to utf-8

[Kinney, Michael D]

Jordan,

I have reviewed the whole series.  Thanks for all the work on this! 

Reviewed-by: Michael Kinney 

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Jordan Justen
> Sent: Friday, December 4, 2015 12:13 PM
> To: edk2-devel@lists.01.org
> Cc: Justen, Jordan L 
> Subject: [edk2] [PATCH v2 00/20] Convert utf-16 .uni files to
> utf-8
> 
> web: https://github.com/jljusten/edk2/tree/uni-to-utf8-v2
> 
> git: https://github.com/jljusten/edk2.git uni-to-utf8-v2
> 
> Jordan Justen (20):
>   BaseTools/Scripts: Add ConvertUni.py script
>   ArmPkg: Convert all .uni files to utf-8
>   ArmPlatformPkg: Convert all .uni files to utf-8
>   CryptoPkg: Convert all .uni files to utf-8
>   DuetPkg: Convert all .uni files to utf-8
>   EmbeddedPkg: Convert all .uni files to utf-8
>   EmulatorPkg: Convert all .uni files to utf-8
>   IntelFrameworkModulePkg: Convert all .uni files to utf-8
>   IntelFrameworkPkg: Convert all .uni files to utf-8
>   MdePkg: Convert all .uni files to utf-8
>   MdeModulePkg: Convert all .uni files to utf-8
>   NetworkPkg: Convert all .uni files to utf-8
>   Nt32Pkg: Convert all .uni files to utf-8
>   PcAtChipsetPkg: Convert all .uni files to utf-8
>   PerformancePkg: Convert all .uni files to utf-8
>   SecurityPkg: Convert all .uni files to utf-8
>   ShellPkg: Convert all .uni files to utf-8
>   SourceLevelDebugPkg: Convert all .uni files to utf-8
>   UefiCpuPkg: Convert all .uni files to utf-8
>   Vlv2TbltDevicePkg: Convert all .uni files to utf-8
> 
>  ArmPkg/Application/LinuxLoader/LinuxLoader.uni | Bin 8166 -
> > 4082 bytes
>  .../ArmShellCmdRunAxf/ArmShellCmdRunAxf.uni| Bin 6472 -
> > 3235 bytes
>  BaseTools/Scripts/ConvertUni.py| 137
> +
>  CryptoPkg/Application/Cryptest/Cryptest.uni| Bin 1924 -
> > 961 bytes
>  CryptoPkg/Application/Cryptest/CryptestExtra.uni   | Bin 1330 -
> > 664 bytes
>  CryptoPkg/CryptRuntimeDxe/CryptRuntimeDxe.uni  | Bin 1968 -
> > 983 bytes
>  CryptoPkg/CryptRuntimeDxe/CryptRuntimeDxeExtra.uni | Bin 1358 -
> > 678 bytes
>  CryptoPkg/CryptoPkg.uni| Bin 2014 -
> > 1006 bytes
>  CryptoPkg/CryptoPkgExtra.uni   | Bin 1344 -
> > 671 bytes
>  CryptoPkg/Library/BaseCryptLib/BaseCryptLib.uni| Bin 2500 -
> > 1249 bytes
>  CryptoPkg/Library/BaseCryptLib/PeiCryptLib.uni | Bin 3990 -
> > 1994 bytes
>  CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.uni | Bin 3634 -
> > 1816 bytes
>  CryptoPkg/Library/BaseCryptLib/SmmCryptLib.uni | Bin 3602 -
> > 1800 bytes
>  .../BaseCryptLibRuntimeCryptProtocol.uni   | Bin 3586 -
> > 1792 bytes
>  .../Library/IntrinsicLib/BaseIntrinsicLib.uni  | Bin 1780 -
> > 889 bytes
>  CryptoPkg/Library/OpensslLib/OpensslLib.uni| Bin 1742 -
> > 870 bytes
>  DuetPkg/SmbiosGenDxe/SmbiosGenStrings.uni  | Bin 2006 -
> > 1002 bytes
>  .../Drivers/FdtPlatformDxe/FdtPlatformDxe.uni  | Bin 9422 -
> > 4710 bytes
>  .../MiscBaseBoardManufacturer.uni  | Bin 2214 -
> > 1106 bytes
>  .../MiscSubClassPlatformDxe/MiscBiosVendor.uni | Bin 1588 -
> > 793 bytes
>  .../MiscChassisManufacturer.uni| Bin 1774 -
> > 886 bytes
>  .../MiscSubClassPlatformDxe/MiscOemString.uni  | Bin 1312 -
> > 655 bytes
>  .../MiscPortInternalConnectorDesignator.uni| Bin 8914 -
> > 4456 bytes
>  .../MiscSubClassPlatformDxe/MiscSubClassDriver.uni | Bin 2004 -
> > 1001 bytes
>  .../MiscSystemLanguageString.uni   | Bin 1314 -
> > 656 bytes
>  .../MiscSystemManufacturer.uni | Bin 1772 -
> > 885 bytes
>  .../MiscSystemOptionString.uni | Bin 1308 -
> > 653 bytes
>  .../MiscSystemSlotDesignation.uni  | Bin 1322 -
> > 660 bytes
>  .../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 

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

[Kinney, Michael D]

Ray,

The UEFI Specification 2.5 p. 136 - CreateEventEx() requires an event group to 
be signaled every time a configuration table is installed or updated.

The RTC driver could create an event notification for the EFI_ACPI_TABLE_GUID 
and cache FADT field in notification function.

Mike

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, December 9, 2015 10:48 AM
> To: Laszlo Ersek <ler...@redhat.com>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Paolo Bonzini 
> <pbonz...@redhat.com>; Scott Duplichan <sc...@notabs.org>;
> edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Zeng, Star 
> <star.z...@intel.com>
> Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang 
> issue
> 
> Laszlo,
> I agree with your concerns that the ACPI table can be modified at anytime 
> before firmware hands off control to OS, after all it's a
> buffer reported by system configuration table. So in extreme cases, a 
> platform may firstly set FADT.century to 0x80 but change it to
> 0x32 later. If the SetTime isn't called later, century won't be saved to 
> CMOS. Even RTC driver hooks the ExitBootServices event to
> update CMOS, the FADT.century may be changed after RTC's callback.
> 
> So how about use a PCD named PcdCmosCenturyLocation type UINT8, and the PCD 
> value should less then 0x80 otherwise assertion in
> RTC driver happens?
> It's platform 's responsibility to convert 0 to 0x80 and save in ACPI table 
> if it's a win-only platform. For a OS neutral platform, non-zero
> PCD should be always chosen.
> 
> 
> 
> Thanks,
> Ray
> 
> > 在 2015年12月10日，02:07，Laszlo Ersek <ler...@redhat.com> 写道：
> >
> >> On 12/09/15 18:55, Kinney, Michael D wrote:
> >> I think we need to evaluate both methods discussed here:
> >>
> >> 1) RTC driver use info from FADT in SetTime() when FADT is available.  Add 
> >> event notification to RTC driver to capture FADT info
> before ExitBootServices().
> >> 2) Use PCD in RTC driver and in ACPI FADT table.
> >>
> >> Advantage of (1) is that it is compatible with existing ACPI Table 
> >> implementations.
> >
> > I agree that (1) is compatible with existing *valid* ACPI table
> > implementations.
> >
> > I can't resist mentioning though that I've seen platform firmware "in
> > the wild" that messed with ACPI tables in the exit-boot-services
> > callback. Obviously this is completely broken: installing new tables
> > involves memory allocation and therefore messes with the memory map.
> >
> > Still, a technically valid driver that is nonetheless too clever for its
> > own good might poke data into existent ACPI tables (without memory
> > allocation or release) at exit-boot-services, derived from other data in
> > the system that *it* expects to become available asynchronously,
> > sometime before exit-boot-services. (Yes, I've seen this happen.)
> >
> > Given that the order of callbacks is unspecified, I generally try to
> > steer clear from inter-module dependencies in any exit-boot-services
> > callback; I believe that any driver should use that callback only for
> > re-setting its internal (software or hardware) state. (Without touching
> > the memory allocation services, of course).
> >
> > I think that the PCD is more robust, and in case a platform's ACPI
> > driver is *not* updated to consider it, then the situation is still no
> > worse than with Ray's current patch, in this thread. As I understand,
> > the PCD can be given a default value that would trigger the behavior
> > proposed in this patch.
> >
> > Thanks
> > Laszlo
> >
> >>
> >> Mike
> >>
> >>
> >>> -Original Message-
> >>> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> >>> Sent: Wednesday, December 9, 2015 9:40 AM
> >>> To: Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D 
> >>> <michael.d.kin...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; Scott
> >>> Duplichan <sc...@notabs.org>
> >>> Cc: 'edk2-devel@lists.01.org' <edk2-de...@ml01.01.org>; Zeng, Star 
> >>> <star.z...@intel.com>
> >>> Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang 
> >>> issue
> >>>
> >>>
> >>>
> >>>> On 09/12/2015 18:37, Laszlo Ersek wrote:
> >>>> - A DXE driver that runs before *both* the ACPI platform DXE driver, and
> >>>> this runtime DXE driver -- to be ordered by any means necessary --, *or*
> >>>> a PEIM, sets a dynamic PCD that keys off *both* the ACPI platform DXE
> >>>> driver and this runtime DXE driver. I think this is the best approach.
> >>>
> >>> Yes, replacing RTC_ADDRESS_CENTURY with a PCD sounds like a very good 
> >>> idea.
> >
> > ___
> > 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] Add QuarkSocPkg and QuarkPlatformPkg packages

[Kinney, Michael D]

Jordan,

Responses below.

I have posted a Quark_V2 branch on github that is synched with the EDK II trunk 
as of today.

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

Thanks,

Mike

> -Original Message-
> From: Justen, Jordan L
> Sent: Thursday, December 10, 2015 10:02 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-
> de...@lists.01.org (edk2-de...@ml01.01.org)  de...@lists.01.org>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: Re: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg
> packages
> 
> On 2015-11-25 00:18:55, Kinney, Michael D wrote:
> > Add 2 packages required for Intel Galileo and Intel Galileo
> Gen 2
> > development  boards with the Quark Soc X1000.
> >
> > Patch email would be a bit large, so here is link to a github
> branch of edk2 with
> > the new package contents for review.
> >
> > https://github.com/mdkinney/edk2/tree/Quark
> 
> Can you rebase your branches before posting them?
> 
> $ git fetch origin
> $ git rebase origin/master
> 
> This can get a little tricky when there are conflicts in the
> changes
> between your branch and the main upstream branch, but your Quark
> branch had no conflicts. (If there are conflicts, you are going
> to
> eventually have to deal with them.)
> 

I just pushed Quark_V2 to github that is rebased to trunk as of a few minutes 
ago and addresses all conflicts and passes your PatchCheck.py script.

> Regarding posting code, does giving a link to a branch cover the
> Contributed-under/Signed-off-by process? I think it might be
> best to
> post the patches and link to the branch. (Although, obviously
> the
> patches themselves would be tough to review directly.)

The patch files are 1.7 MB and 1.5 MB.  Very big to send to edk2-devel.  Any 
suggestions?

> 
> Neither QuarkSocPkg, nor QuarkPlatformPkg have a License.txt.
> Generally we'd want to just copy it from MdePkg.

I have fixed this in the Quark_V2 branch on github.

> 
> I see QuarkSocPkg/QuarkNorthCluster/Binary/QuarkMicrocode...
> Well, at
> least, unlike Vlv2TbltDevicePkg/Stitch, the size is reasonable.
> :)
> 
> I don't think it should be included in the same package as
> otherwise
> BSD licensed code. I think you should put it into a separate
> package,
> or perhaps repo, and you should mention the different license,
> since
> it is not covered by MdePkg/Contributions.txt. There has been
> some
> talk of removing FatBinPkg from the tree due to the license, so
> where
> does that leave this module?

I prefer to keep this in the same package because it is associated 
directly with the QuarkSoc. What about this license do you think is 
not compatible with the contributor's agreement?  We prefer BSD, 
but other licenses are allowed.

> 
> Regarding
> QuarkSocPkg/QuarkNorthCluster/Binary/QuarkMicrocode/IntelProprie
> taryLicense.txt,
> can it be renamed to License.txt? MdePkg/Contributions.txt only
> mentions License.txt.
> 
> -Jordan
> 
> >
> > The QuarkPlatformPkg has 2 DSC files
> > 
> > Quark.dscSupports full
> configuration
> > QuarkMin.dscMin config for initial power-
> on/debug
> >
> > Quark.dsc supports the following defines
> > 
> > GALILEO
> > LOGGING
> > SOURCE_DEBUG_ENABLE
> > SECURE_BOOT_ENABLE
> > PERFORMANCE_ENABLE
> >
> > Example build command for Galileo
> >
> > build -a IA32 -t VS2013x86 -p
> QuarkPlatformPkg/Quark.dsc -D GALILEO=GEN1
> >
> > Example build command for Galileo GEN2
> >
> > build -a IA32 -t VS2013x86 -p
> QuarkPlatformPkg/Quark.dsc
> >
> > The default serial console for Galileo is 460800n81
> > The default serial console for Galileo Gen 2 is 921600n81
> >
> > There is more work to add features and clean up some code
> style
> > issues, but this initial set of content boots to the UEFI
> shell and the
> > operating systems supported by Galileo.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Michael Kinney
> <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
> >
> >
> >
> > ___
> > 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] Add QuarkSocPkg and QuarkPlatformPkg packages

[Kinney, Michael D]

Here are some more details on Quark_V2

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

QuarkSocPkg: Add new package for Quark SoC X1000

Changes for V2
1) Sync with new APIs in SmmCpuFeaturesLib class
2) Use new generic PCI serial driver PciSioSerialDxe in MdeModulePkg
3) Remove PCI serial driver from QuarkSocPkg
4) Apply optimizations to MtrrLib from MtrrLib in UefiCpuPkg
5) Convert all UNI files to utf-8
6) Replace tabs with spaces and remove trailing spaces
7) Add License.txt

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



QuarkPlatformPkg: Add new package for Galileo boards

Changes for V2
1) Use new generic PCI serial driver PciSioSerialDxe in MdeModulePkg
2) Configure PcdPciSerialParameters for PCI serial driver for Quark
3) Use new MtrrLib API to reduce time to set MTRRs for all DRAM
4) Convert all UNI files to utf-8
5) Replace tabs with spaces and remove trailing spaces
6) Add License.txt

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


Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, December 10, 2015 10:25 PM
> To: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-
> de...@lists.01.org (edk2-de...@ml01.01.org)  de...@lists.01.org>; Kinney, Michael D
> <michael.d.kin...@intel.com>
> Subject: RE: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg
> packages
> 
> Jordan,
> 
> Responses below.
> 
> I have posted a Quark_V2 branch on github that is synched with
> the EDK II trunk as of today.
> 
> https://github.com/mdkinney/edk2/tree/Quark_V2
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Justen, Jordan L
> > Sent: Thursday, December 10, 2015 10:02 PM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-
> > de...@lists.01.org (edk2-de...@ml01.01.org)  > de...@lists.01.org>
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> > Subject: Re: [edk2] [PATCH] Add QuarkSocPkg and
> QuarkPlatformPkg
> > packages
> >
> > On 2015-11-25 00:18:55, Kinney, Michael D wrote:
> > > Add 2 packages required for Intel Galileo and Intel Galileo
> > Gen 2
> > > development  boards with the Quark Soc X1000.
> > >
> > > Patch email would be a bit large, so here is link to a
> github
> > branch of edk2 with
> > > the new package contents for review.
> > >
> > > https://github.com/mdkinney/edk2/tree/Quark
> >
> > Can you rebase your branches before posting them?
> >
> > $ git fetch origin
> > $ git rebase origin/master
> >
> > This can get a little tricky when there are conflicts in the
> > changes
> > between your branch and the main upstream branch, but your
> Quark
> > branch had no conflicts. (If there are conflicts, you are
> going
> > to
> > eventually have to deal with them.)
> >
> 
> I just pushed Quark_V2 to github that is rebased to trunk as of
> a few minutes ago and addresses all conflicts and passes your
> PatchCheck.py script.
> 
> > Regarding posting code, does giving a link to a branch cover
> the
> > Contributed-under/Signed-off-by process? I think it might be
> > best to
> > post the patches and link to the branch. (Although, obviously
> > the
> > patches themselves would be tough to review directly.)
> 
> The patch files are 1.7 MB and 1.5 MB.  Very big to send to
> edk2-devel.  Any suggestions?
> 
> >
> > Neither QuarkSocPkg, nor QuarkPlatformPkg have a License.txt.
> > Generally we'd want to just copy it from MdePkg.
> 
> I have fixed this in the Quark_V2 branch on github.
> 
> >
> > I see QuarkSocPkg/QuarkNorthCluster/Binary/QuarkMicrocode...
> > Well, at
> > least, unlike Vlv2TbltDevicePkg/Stitch, the size is
> reasonable.
> > :)
> >
> > I don't think it should be included in the same package as
> > otherwise
> > BSD licensed code. I think you should put it into a separate
> > package,
> > or perhaps repo, and you should mention the different license,
> > since
> > it is not covered by MdePkg/Contributions.txt. There has been
> > some
> > talk of removing FatBinPkg from the tree due to the license,
> so
> > where
> > does that leave this module?
> 
> I prefer to keep this in the same package because it is
> associated
> directly with the QuarkSoc. What about this license do you think
> is
> not compatible with the contributor's agreement?  We prefer BSD,
> but other licenses are allowed.
> 
> >
> > Regarding
>

Re: [edk2] [Patch] ShellPkg/Mm: Fix build warnings

[Kinney, Michael D]

Jaben,

Eric Tian made the commit.  Can you please verify that it was rebased correctly.

Thanks,

Mike

> -Original Message-
> From: Carsey, Jaben
> Sent: Monday, December 14, 2015 8:12 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-
> de...@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Carsey, Jaben
> <jaben.car...@intel.com>
> Subject: RE: [Patch] ShellPkg/Mm: Fix build warnings
> 
> Mike,
> 
> Your second patch needs to be rebased.  This is changing some of
> the lines that were changed with the most recent patch to this
> file.
> 
> -Jaben
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Saturday, December 12, 2015 1:50 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Carsey, Jaben
> <jaben.car...@intel.com>
> > Subject: [Patch] ShellPkg/Mm: Fix build warnings
> > Importance: High
> >
> > Fix build warnings for potentially uninitialized local
> variables
> > in the functions ShellMmLocateIoProtocol() and
> ShellCommandRunMm()
> > in the Shell implementation of the 'mm' command.
> >
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Jaben Carsey <jaben.car...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
> > ---
> >  ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c | 24
> +-
> > --
> >  1 file changed, 13 insertions(+), 11 deletions(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c
> > b/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c
> > index 3f08cc8..1e2c0cb 100644
> > --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c
> > +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Mm.c
> > @@ -328,6 +328,8 @@ ShellMmLocateIoProtocol (
> >  return FALSE;
> >}
> >
> > +  Segment = 0;
> > +  Bus = 0;
> >if ((AccessType == ShellMmPci) || (AccessType ==
> ShellMmPciExpress)) {
> >  ShellMmDecodePciAddress ((BOOLEAN) (AccessType ==
> ShellMmPci),
> > Address, , , NULL, NULL, NULL);
> >}
> > @@ -614,18 +616,18 @@ ShellCommandRunMm (
> >  // skip space characters
> >  //
> >  for (Index = 0; InputStr[Index] == ' '; Index++);
> > -  }
> >
> > -  if ((InputStr != NULL) && (InputStr[Index] !=
> CHAR_NULL)) {
> > -if ((InputStr[Index] == '.') || (InputStr[Index] ==
> 'q') || (InputStr[Index] ==
> > 'Q')) {
> > -  Complete = TRUE;
> > -} else if (!EFI_ERROR (ShellConvertStringToUint64
> (InputStr + Index,
> > , TRUE, TRUE)) &&
> > -   (Buffer <= mShellMmMaxNumber[Size])
> > -   ) {
> > -  ShellMmAccess (AccessType, PciRootBridgeIo, CpuIo,
> FALSE, Address,
> > Size, );
> > -} else {
> > -  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> (STR_MM_ERROR),
> > gShellDebug1HiiHandle, L"mm");
> > -  continue;
> > +if ((InputStr[Index] != CHAR_NULL)) {
> > +  if ((InputStr[Index] == '.') || (InputStr[Index] ==
> 'q') || (InputStr[Index]
> > == 'Q')) {
> > +Complete = TRUE;
> > +  } else if (!EFI_ERROR (ShellConvertStringToUint64
> (InputStr + Index,
> > , TRUE, TRUE)) &&
> > + (Buffer <= mShellMmMaxNumber[Size])
> > + ) {
> > +ShellMmAccess (AccessType, PciRootBridgeIo,
> CpuIo, FALSE, Address,
> > Size, );
> > +  } else {
> > +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> (STR_MM_ERROR),
> > gShellDebug1HiiHandle, L"mm");
> > +continue;
> > +  }
> >  }
> >}
> >
> > --
> > 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/7] MdeModulePkg: Add IpmiLib and Ppi/Protocol header file.

[Kinney, Michael D]

Daocheng Bu,

This patch appears to contain both additions to the DEC file and white space 
clean up of the DEC file.  Can you please split these into separate patches?

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Daocheng Bu
> Sent: Tuesday, December 22, 2015 8:03 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [edk2] [PATCH v3 2/7] MdeModulePkg: Add IpmiLib and Ppi/Protocol 
> header
> file.
> 
> Add IpmiLib and Ppi/Protocol header file. Update dec file
> for new IpmiLib and Ppi/Protocol header file.
> 
> In V3,removed the first '_' in GUID name.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Daocheng Bu 
> Cc: Liming Gao 
> ---
>  MdeModulePkg/Include/Library/IpmiLib.h   |  51 ++
>  MdeModulePkg/Include/Ppi/IpmiPpi.h   |  65 +
>  MdeModulePkg/Include/Protocol/IpmiProtocol.h |  72 +++
>  MdeModulePkg/MdeModulePkg.dec| 101 
> +++
>  4 files changed, 244 insertions(+), 45 deletions(-)
>  create mode 100644 MdeModulePkg/Include/Library/IpmiLib.h
>  create mode 100644 MdeModulePkg/Include/Ppi/IpmiPpi.h
>  create mode 100644 MdeModulePkg/Include/Protocol/IpmiProtocol.h
> 
> diff --git a/MdeModulePkg/Include/Library/IpmiLib.h
> b/MdeModulePkg/Include/Library/IpmiLib.h
> new file mode 100644
> index 000..2909adb
> --- /dev/null
> +++ b/MdeModulePkg/Include/Library/IpmiLib.h
> @@ -0,0 +1,51 @@
> +/** @file
> +  This library abstract how to access IPMI device via IPMI command.
> +
> +Copyright (c) 2011 - 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
> +
> +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 _IPMI_LIB_H_
> +#define _IPMI_LIB_H_
> +
> +#include 
> +#include 
> +
> +
> +/**
> +  This service enables submitting commands via Ipmi.
> +
> +  @param[in] NetFunction   Net function of the command.
> +  @param[in] Command   IPMI Command.
> +  @param[in] RequestData   Command Request Data.
> +  @param[in] RequestDataSize   Size of Command Request Data.
> +  @param[out]ResponseData  Command Response Data. The completion 
> code is
> the first byte of response data.
> +  @param[in out] ResponseDataSize  Size of Command Response Data.
> +
> +  @retval EFI_SUCCESSThe command byte stream was successfully 
> submit to
> the device and a response was successfully received.
> +  @retval EFI_NOT_FOUND  The command was not successfully sent to 
> the device
> or a response was not successfully received from the device.
> +  @retval EFI_NOT_READY  Ipmi Device is not ready for Ipmi command 
> access.
> +  @retval EFI_DEVICE_ERROR   Ipmi Device hardware error.
> +  @retval EFI_TIMEOUTThe command time out.
> +  @retval EFI_UNSUPPORTEDThe command was not successfully sent to the
> device.
> +  @retval EFI_OUT_OF_RESOURCES   The resource allcation is out of resource 
> or data
> size error.
> +**/
> +EFI_STATUS
> +EFIAPI
> +IpmiSubmitCommand (
> +  IN UINT8 NetFunction,
> +  IN UINT8 Command,
> +  IN UINT8 *RequestData,
> +  IN UINT32RequestDataSize,
> + OUT UINT8 *ResponseData,
> +  IN OUT UINT32*ResponseDataSize
> +  );
> +
> +#endif
> diff --git a/MdeModulePkg/Include/Ppi/IpmiPpi.h 
> b/MdeModulePkg/Include/Ppi/IpmiPpi.h
> new file mode 100644
> index 000..b743b61
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/IpmiPpi.h
> @@ -0,0 +1,65 @@
> +/** @file
> +  Ppi for Ipmi of SMS.
> +
> +  Copyright (c) 2014 - 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.
> +
> +  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 _IPMI_PPI_H_
> +#define _IPMI_PPI_H_
> +
> +typedef struct _PEI_IPMI_PPI PEI_IPMI_PPI;
> +
> +#define PEI_IPMI_PPI_GUID \
> +  { \
> +0xa9731431, 0xd968, 0x4277, 0xb7, 0x52, 0xa3, 0xa9, 0xa6, 0xae, 0x18, 
> 0x98 \
> +  }
> +
> +/**
> +  This service enables submitting commands via Ipmi.
> +
> +  @param[in] This  This point for PEI_IPMI_PPI 

Re: [edk2] how to develop an UEFI runtime driver

[Kinney, Michael D]

A good place to start is the UEFI Driver Writer's Guide

https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer's-Guide

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> LiHongcheng
> Sent: Tuesday, December 22, 2015 8:01 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] how to develop an UEFI runtime driver
> 
> Dear Sir/Madam,
>   My name is Owen and I am a senior student in college. Recently I was 
> asked to
> develop a simple runtime driver but have no idea about it. I’ve had some basic
> knowledge about UEFI and can write some simple applications. However I can 
> not find
> much information about runtime driver. Could you please shed some lights on 
> me, that
> would be really great. Thank you very much!
>   Best wishes.
> 发送自 Windows 10 版邮件应用
> 
> ___
> 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] MdePkg : Update SPCR to use ACPI5 definition

[Kinney, Michael D]

Samer,

Thanks.  I agree that SPCR spec just uses the term Generic Address Structure 
without a version.

Updating to a newer version of the struct is ok as long as the newer version is 
backwards compatible with the previous version.

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

Mike

> -Original Message-
> From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
> Sent: Tuesday, December 22, 2015 7:54 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming@intel.com>; Shifflett, Joseph 
> <joseph.shiffl...@hpe.com>;
> El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>
> Subject: RE: [PATCH] MdePkg : Update SPCR to use ACPI5 definition
> 
> Mike,
> 
> Yes we ran into specific devices that require this.
> 
> In general, ARM SoC's will memory map UART resources.  It is important to be 
> able to
> indicate to the OS the permitted size of the memory transactions when 
> accessing these
> resources.
> 
> The SPCR spec was not changed to indicate that it uses the latest Generic 
> Address
> Structure, but it does specifically indicate that it uses the Generic Address
> Structure.
> The SPCR spec has been updated since the Generic Address Structure was 
> updated to add
> AccessWidth (post 2.0),  so it could be implied that the SPCR assumes the 
> latest
> Generic Address Structure...
> 
> Thanks,
> --Samer
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Tuesday, December 22, 2015 9:51 AM
> To: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; 
> edk2-devel@lists.01.org
> Cc: Gao, Liming <liming@intel.com>; El-Haj-Mahmoud, Samer  mahm...@hpe.com>
> Subject: RE: [PATCH] MdePkg : Update SPCR to use ACPI5 definition
> 
> Samer,
> 
> Why is this change being made?  I did not see an update to the SPCR spec to 
> require
> the ACPI 5.0 descriptor.
> 
> Is there a device that requires the AccessSize field and OSes use the 
> AccessSize
> field?
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Samer El-Haj-Mahmoud [mailto:samer.el-haj-mahm...@hpe.com]
> > Sent: Monday, December 21, 2015 4:50 PM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> > <liming@intel.com>; Samer El-Haj-Mahmoud
> > <samer.el-haj-mahm...@hpe.com>; Samer El-Haj-Mahmoud <el...@hpe.com>
> > Subject: [PATCH] MdePkg : Update SPCR to use ACPI5 definition
> >
> > Update BaseAddress in the SPCR structure to use
> > EFI_ACPI_5_0_GENERIC_ADDRESS_STRUCTURE
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Samer El-Haj-Mahmoud <el...@hpe.com>
> > ---
> >  MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h |
> > 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > index bf29505..d57518d 100644
> > ---
> > a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > +++ b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTabl
> > +++ e.h
> > @@ -3,6 +3,7 @@
> >http://www.microsoft.com/whdc/system/platform/server/spcr.mspx
> >
> >Copyright (c) 2007 - 2015, 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
> >which accompanies this distribution.  The full text of the license
> > may be found at @@ -35,7 +36,7 @@ typedef struct {
> >EFI_ACPI_DESCRIPTION_HEADER Header;
> >UINT8   InterfaceType;
> >UINT8   Reserved1[3];
> > -  EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE  BaseAddress;
> > +  EFI_ACPI_5_0_GENERIC_ADDRESS_STRUCTURE  BaseAddress;
> >UINT8   InterruptType;
> >UINT8   Irq;
> >UINT32  GlobalSystemInterrupt;
> > --
> > 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] MdePkg : Update SPCR to use ACPI5 definition

[Kinney, Michael D]

Committed r19456

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney,
> Michael D
> Sent: Tuesday, December 22, 2015 8:30 AM
> To: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; 
> edk2-devel@lists.01.org
> Cc: Shifflett, Joseph <joseph.shiffl...@hpe.com>; Gao, Liming 
> <liming@intel.com>
> Subject: Re: [edk2] [PATCH] MdePkg : Update SPCR to use ACPI5 definition
> 
> Samer,
> 
> Thanks.  I agree that SPCR spec just uses the term Generic Address Structure 
> without
> a version.
> 
> Updating to a newer version of the struct is ok as long as the newer version 
> is
> backwards compatible with the previous version.
> 
> Reviewed-by: Michael Kinney <michael.d.kin...@intel.com>
> 
> Mike
> 
> > -Original Message-
> > From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
> > Sent: Tuesday, December 22, 2015 7:54 AM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming@intel.com>; Shifflett, Joseph
> <joseph.shiffl...@hpe.com>;
> > El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>
> > Subject: RE: [PATCH] MdePkg : Update SPCR to use ACPI5 definition
> >
> > Mike,
> >
> > Yes we ran into specific devices that require this.
> >
> > In general, ARM SoC's will memory map UART resources.  It is important to 
> > be able
> to
> > indicate to the OS the permitted size of the memory transactions when 
> > accessing
> these
> > resources.
> >
> > The SPCR spec was not changed to indicate that it uses the latest Generic 
> > Address
> > Structure, but it does specifically indicate that it uses the Generic 
> > Address
> > Structure.
> > The SPCR spec has been updated since the Generic Address Structure was 
> > updated to
> add
> > AccessWidth (post 2.0),  so it could be implied that the SPCR assumes the 
> > latest
> > Generic Address Structure...
> >
> > Thanks,
> > --Samer
> >
> > -Original Message-
> > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > Sent: Tuesday, December 22, 2015 9:51 AM
> > To: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; 
> > edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming@intel.com>; El-Haj-Mahmoud, Samer  > mahm...@hpe.com>
> > Subject: RE: [PATCH] MdePkg : Update SPCR to use ACPI5 definition
> >
> > Samer,
> >
> > Why is this change being made?  I did not see an update to the SPCR spec to 
> > require
> > the ACPI 5.0 descriptor.
> >
> > Is there a device that requires the AccessSize field and OSes use the 
> > AccessSize
> > field?
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Samer El-Haj-Mahmoud [mailto:samer.el-haj-mahm...@hpe.com]
> > > Sent: Monday, December 21, 2015 4:50 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> > > <liming@intel.com>; Samer El-Haj-Mahmoud
> > > <samer.el-haj-mahm...@hpe.com>; Samer El-Haj-Mahmoud <el...@hpe.com>
> > > Subject: [PATCH] MdePkg : Update SPCR to use ACPI5 definition
> > >
> > > Update BaseAddress in the SPCR structure to use
> > > EFI_ACPI_5_0_GENERIC_ADDRESS_STRUCTURE
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Samer El-Haj-Mahmoud <el...@hpe.com>
> > > ---
> > >  MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h |
> > > 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > > b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > > index bf29505..d57518d 100644
> > > ---
> > > a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > > +++ b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTabl
> > > +++ e.h
> > > @@ -3,6 +3,7 @@
> > >http://www.microsoft.com/whdc/system/platform/server/spcr.mspx
> > >
> > >Copyright (c) 2007 - 2015, Intel Corporation. All rights
> > > reserved.
> > > +  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
> > >This program and the accompanying materials
> > >are licensed and made ava

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

[Kinney, Michael D]

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 v2 0/7] Support the different AP loop mode

[Kinney, Michael D]

Jeff,

The updates to the series looks good.
 
Reviewed-by: Michael Kinney 

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Jeff Fan
> Sent: Thursday, December 17, 2015 6:17 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch v2 0/7] Support the different AP loop
> mode
> 
> v2:
> (1) Per Michael Kinney's suggestion, update GetApLoopMode() not
> to check CPUID
> on MONITOR/MWAIT support if PcdCpuApLoopMode is not set to
> ApMwaitLoop.
> (2) Add PcdCpuApTargetCstate to specify the C-state for APs
> instead of the max
> C-state.
> 
> v1:
> Support 3 AP loop modes:
> A: Place AP in the Hlt-Loop state.
> B: Place AP in the Mwait-Loop state.
> C: Place AP in the Run-Loop state.
> 
> Jeff Fan (7):
>   UefiCpuPkg: Add PCD PcdCpuApLoopMode
>   UefiCpuPkg: Add PCD PcdCpuApTargetCstate
>   UefiCpuPkg/CpuMpPei: Add GetApLoopMode() to get AP loop mode
>   UefiCpuPkg/CpuMpPei: Prepare for monitor buffer
>   UefiCpuPkg/CpuMpPei: Place APs in proper loop mode after AP
> execution
>   UefiCpuPkg/CpuMpPei: Wake up APs by proper method
>   UefiCpuPkg/CpuMpPei: Remove un-used AsmCliHltLoop()
> 
>  UefiCpuPkg/CpuMpPei/CpuMpPei.c| 264
> +++---
>  UefiCpuPkg/CpuMpPei/CpuMpPei.h|  26 ++--
>  UefiCpuPkg/CpuMpPei/CpuMpPei.inf  |   3 +
>  UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.asm  |   6 -
>  UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.nasm |   6 -
>  UefiCpuPkg/CpuMpPei/PeiMpServices.c   |   6 +-
>  UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm   |   6 -
>  UefiCpuPkg/CpuMpPei/X64/MpFuncs.nasm  |   6 -
>  UefiCpuPkg/Include/Register/Cpuid.h   |   2 +
>  UefiCpuPkg/UefiCpuPkg.dec |  13 ++
>  UefiCpuPkg/UefiCpuPkg.uni | Bin 22498 -> 23534
> bytes
>  11 files changed, 244 insertions(+), 94 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] UefiCpuPkg/PiSmmCpu: Move SmmDebug from ASM to C.

[Kinney, Michael D]

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


> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, November 24, 2015 12:50 AM
> To: edk2-de...@ml01.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Fan, Jeff <jeff@intel.com>; 
> Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: [patch] UefiCpuPkg/PiSmmCpu: Move SmmDebug from ASM to C.
> 
> SmmDebug feature is implemented in ASM, which is not easy to maintain.
> SO we move it to C function.
> 
> 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/SmiEntry.S   | 44 ++---
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm | 48 ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c   | 59 
> +
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S| 39 +++
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm  | 47 ---
>  5 files changed, 114 insertions(+), 123 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.S 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.S
> index 6fcf41a..fbaa072 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.S
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.S
> @@ -24,7 +24,6 @@ ASM_GLOBAL  ASM_PFX(gcSmiHandlerSize)
>  ASM_GLOBAL  ASM_PFX(gSmiCr3)
>  ASM_GLOBAL  ASM_PFX(gSmiStack)
>  ASM_GLOBAL  ASM_PFX(gSmbase)
> -ASM_GLOBAL  ASM_PFX(FeaturePcdGet (PcdCpuSmmDebug))
>  ASM_GLOBAL  ASM_PFX(FeaturePcdGet (PcdCpuSmmStackGuard))
>  ASM_GLOBAL  ASM_PFX(gSmiHandlerIdtr)
> 
> @@ -148,43 +147,22 @@ L5:
>  #   jmp _SmiHandler # instruction is not needed
> 
>  _SmiHandler:
> -cmpb$0, ASM_PFX(FeaturePcdGet (PcdCpuSmmDebug))
> -jz  L3
> -
> -L6:
> -callL1
> -L1:
> -popl%ebp
> -movl$0x8001, %eax
> -cpuid
> -btl $29, %edx   # check cpuid to identify X64 or IA32
> -leal(0x7fc8 - (L1 - _SmiEntryPoint))(%ebp), %edi
> -leal4(%edi), %esi
> -jnc L2
> -addl$4, %esi
> -L2:
> -movl(%esi), %ecx
> -movl(%edi), %edx
> -L7:
> -movl%ecx, %dr6
> -movl%edx, %dr7  # restore DR6 & DR7 before running C 
> code
> -L3:
> -
> -pushl   (%esp)
> +movl(%esp), %ebx
> 
> +pushl   %ebx
> +movl$ASM_PFX(CpuSmmDebugEntry), %eax
> +call*%eax
> +popl%ecx
> +
> +pushl   %ebx
>  movl$ASM_PFX(SmiRendezvous), %eax
>  call*%eax
>  popl%ecx
> 
> -
> -cmpb$0, ASM_PFX(FeaturePcdGet (PcdCpuSmmDebug))
> -jz  L4
> -
> -movl%dr6, %ecx
> -movl%dr7, %edx
> -movl%ecx, (%esi)
> -movl%edx, (%edi)
> -L4:
> +pushl   %ebx
> +movl$ASM_PFX(CpuSmmDebugExit), %eax
> +call*%eax
> +popl%ecx
> 
>  rsm
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm
> index b628fe8..8a12927 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm
> @@ -34,14 +34,15 @@ PROTECT_MODE_CS EQU   08h
>  PROTECT_MODE_DS EQU   20h
>  TSS_SEGMENT EQU   40h
> 
> -SmiRendezvous   PROTO   C
> +SmiRendezvous  PROTO   C
> +CpuSmmDebugEntry   PROTO   C
> +CpuSmmDebugExitPROTO   C
> 
>  EXTERNDEF   gcSmiHandlerTemplate:BYTE
>  EXTERNDEF   gcSmiHandlerSize:WORD
>  EXTERNDEF   gSmiCr3:DWORD
>  EXTERNDEF   gSmiStack:DWORD
>  EXTERNDEF   gSmbase:DWORD
> -EXTERNDEF   FeaturePcdGet (PcdCpuSmmDebug):BYTE
>  EXTERNDEF   FeaturePcdGet (PcdCpuSmmStackGuard):BYTE
>  EXTERNDEF   gSmiHandlerIdtr:FWORD
> 
> @@ -151,40 +152,23 @@ gSmiCr3 DD  ?
>  ;   jmp _SmiHandler ; instruction is not needed
> 
>  _SmiHandler PROC
> -cmp FeaturePcdGet (PcdCpuSmmDebug), 0
> -jz  @3
> -call@1
> -@1:
> -pop ebp
> -mov eax, 8001h
> -cpuid
> -bt  edx, 29 ; check cpuid to identify X64 or IA32
> -lea edi, [ebp - (@1 - _SmiEntryPoint) + 7fc8h]
> -lea esi, [edi + 4]
> -jnc @2
> -add esi, 4
> -@2:
> -mov ecx, [esi]
> -mov edx, [edi]
> -@5:
> -mov dr6, ecx
> -mov dr7, edx; restore DR6 & DR7 before running C 
> code
> -@3:
> -mov ecx,

Re: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Move RestoreSmmConfigurationInS3 function to PerformPreTasks().

[Kinney, Michael D]

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

> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, November 24, 2015 12:36 AM
> To: edk2-de...@ml01.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Fan, Jeff <jeff@intel.com>; 
> Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo
> Ersek <ler...@redhat.com>
> Subject: [patch] UefiCpuPkg/PiSmmCpu: Move RestoreSmmConfigurationInS3 
> function to PerformPreTasks().
> 
> In this way, we can centralize the silicon configuration in
>  PerformRemainingTasks()/PerformPreTasks() function.
> If there are more features need to be configured, they can put in
>  PerformRemainingTasks()/PerformPreTasks() only.
> 
> 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>
> Cc: "Laszlo Ersek" <ler...@redhat.com>
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  | 10 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 22 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  9 +
>  3 files changed, 33 insertions(+), 8 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 730c32d..d20aa27 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -412,15 +412,9 @@ BSPHandler (
>AcquireSpinLockOrFail (>CpuData[CpuIndex].Busy);
> 
>//
> -  // Restore SMM Configuration in S3 boot path.
> +  // Perform the pre tasks
>//
> -  if (mRestoreSmmConfigurationInS3) {
> -//
> -// Configure SMM Code Access Check feature if available.
> -//
> -ConfigSmmCodeAccessCheck ();
> -mRestoreSmmConfigurationInS3 = FALSE;
> -  }
> +  PerformPreTasks ();
> 
>//
>// Invoke SMM Foundation EntryPoint with the processor information context.
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> index 532ac09..2489848 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> @@ -1437,3 +1437,25 @@ PerformRemainingTasks (
>  mSmmReadyToLock = FALSE;
>}
>  }
> +
> +/**
> +  Perform the pre tasks.
> +
> +**/
> +VOID
> +PerformPreTasks (
> +  VOID
> +  )
> +{
> +  //
> +  // Restore SMM Configuration in S3 boot path.
> +  //
> +  if (mRestoreSmmConfigurationInS3) {
> +//
> +// Configure SMM Code Access Check feature if available.
> +//
> +ConfigSmmCodeAccessCheck ();
> +
> +mRestoreSmmConfigurationInS3 = FALSE;
> +  }
> +}
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> index cfbf2ca..96d55c0 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> @@ -572,6 +572,15 @@ PerformRemainingTasks (
>);
> 
>  /**
> +  Perform the pre tasks.
> +
> +**/
> +VOID
> +PerformPreTasks (
> +  VOID
> +  );
> +
> +/**
>Initialize MSR spin lock by MSR index.
> 
>@param  MsrIndex   MSR index value.
> --
> 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 v2 1/2] UefiCpuPkg/CpuMpPei: Set X2APIC flag if one x2APIC ID larger than 254

[Kinney, Michael D]

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


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff 
> Fan
> Sent: Tuesday, November 24, 2015 12:55 AM
> To: edk2-de...@ml01.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Tian, Feng 
> <feng.t...@intel.com>
> Subject: [edk2] [Patch v2 1/2] UefiCpuPkg/CpuMpPei: Set X2APIC flag if one 
> x2APIC ID larger than 254
> 
> If there are any logical processor reporting an APIC ID of 255 or greater, set
> X2ApicEnable flag.
> 
> GetInitialApicId() will return x2APIC ID if CPUID leaf B supported.
> 
> 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 | 21 -
>  UefiCpuPkg/CpuMpPei/CpuMpPei.h |  2 ++
>  2 files changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> index 8e35f28..8ed5243 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> @@ -146,11 +146,20 @@ 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;
> +PeiCpuMpData->CpuData[NumApsExecuting].ApicId = GetInitialApicId ();
> +if (PeiCpuMpData->CpuData[NumApsExecuting].ApicId >= 0xFF) {
> +  //
> +  // Set x2APIC mode if there are any logical processor reporting
> +  // an APIC ID of 255 or greater.
> +  //
> +  AcquireSpinLock(>MpLock);
> +  PeiCpuMpData->X2ApicEnable = TRUE;
> +  ReleaseSpinLock(>MpLock);
> +}
>  //
>  // Sync BSP's Mtrr table to all wakeup APs and load microcode on APs.
>  //
> @@ -363,15 +372,16 @@ CountProcessorNumber (
>//
>if (PcdGet32 (PcdCpuMaxLogicalProcessorNumber) > 1) {
>  //
> -// Send broadcast IPI to APs to wakeup APs
> +// Send 1st broadcast IPI to APs to wakeup APs
>  //
> -PeiCpuMpData->InitFlag = 1;
> +PeiCpuMpData->InitFlag = TRUE;
> +PeiCpuMpData->X2ApicEnable = FALSE;
>  WakeUpAP (PeiCpuMpData, TRUE, 0, NULL, NULL);
>  //
>  // Wait for AP task to complete and then exit.
>  //
>  MicroSecondDelay (PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds));
> -PeiCpuMpData->InitFlag = 0;
> +PeiCpuMpData->InitFlag  = FALSE;
>  PeiCpuMpData->CpuCount += 
> (UINT32)PeiCpuMpData->MpCpuExchangeInfo->NumApsExecuting;
>  ASSERT (PeiCpuMpData->CpuCount <= PcdGet32 
> (PcdCpuMaxLogicalProcessorNumber));
>  //
> @@ -439,6 +449,7 @@ PrepareAPStartupVector (
>PeiCpuMpData->CpuData[0].ApicId= GetInitialApicId ();
>PeiCpuMpData->CpuData[0].Health.Uint32 = 0;
>PeiCpuMpData->EndOfPeiFlag = FALSE;
> +  InitializeSpinLock(>MpLock);
>CopyMem (>AddressMap, , sizeof 
> (MP_ASSEMBLY_ADDRESS_MAP));
> 
>//
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.h b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> index 9325a12..de90113 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> @@ -124,6 +124,7 @@ typedef struct {
>  // PEI CPU MP Data save in memory
>  //
>  struct _PEI_CPU_MP_DATA {
> +  SPIN_LOCK  MpLock;
>UINT32 CpuCount;
>UINT32 BspNumber;
>UINTN  Buffer;
> @@ -137,6 +138,7 @@ struct _PEI_CPU_MP_DATA {
>volatile UINT32FinishedCount;
>BOOLEANEndOfPeiFlag;
>BOOLEANInitFlag;
> +  BOOLEANX2ApicEnable;
>CPU_EXCHANGE_ROLE_INFO BSPInfo;
>CPU_EXCHANGE_ROLE_INFO APInfo;
>MTRR_SETTINGS  MtrrTable;
> --
> 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 2/2] UefiCpuPkg/CpuMpPei: Enable x2APIC mode on BSP/APs

[Kinney, Michael D]

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

> -Original Message-
> From: Fan, Jeff
> Sent: Tuesday, November 24, 2015 12:55 AM
> To: edk2-de...@ml01.01.org
> Cc: Tian, Feng <feng.t...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Subject: [Patch v2 2/2] UefiCpuPkg/CpuMpPei: Enable x2APIC mode on BSP/APs
> 
> If x2APIC flag is set, enable x2APIC mode on all APs and BSP. Before we wakeup
> APs to enable x2APIC mode, we should wait all APs have finished 
> initialization.
> 
> 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 | 39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> index 8ed5243..c222522 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> @@ -102,6 +102,20 @@ SortApicId (
>  }
> 
>  /**
> +  Enable x2APIC mode on APs.
> +
> +  @param Buffer  Pointer to private data buffer.
> +**/
> +VOID
> +EFIAPI
> +ApFuncEnableX2Apic (
> +  IN OUT VOID  *Buffer
> +  )
> +{
> +  SetApicMode (LOCAL_APIC_MODE_X2APIC);
> +}
> +
> +/**
>Get CPU MP Data pointer from the Guided HOB.
> 
>@return  Pointer to Pointer to PEI CPU MP Data
> @@ -385,6 +399,31 @@ CountProcessorNumber (
>  PeiCpuMpData->CpuCount += 
> (UINT32)PeiCpuMpData->MpCpuExchangeInfo->NumApsExecuting;
>  ASSERT (PeiCpuMpData->CpuCount <= PcdGet32 
> (PcdCpuMaxLogicalProcessorNumber));
>  //
> +// Wait for all APs finished the initialization
> +//
> +while (PeiCpuMpData->FinishedCount < (PeiCpuMpData->CpuCount - 1)) {
> +  CpuPause ();
> +}
> +
> +if (PeiCpuMpData->X2ApicEnable) {
> +  DEBUG ((EFI_D_INFO, "Force x2APIC mode!\n"));
> +  //
> +  // Send 2nd broadcast IPI to all APs to enable x2APIC mode
> +  //
> +  WakeUpAP (PeiCpuMpData, TRUE, 0, ApFuncEnableX2Apic, NULL);
> +  //
> +  // Wait for all known APs finished
> +  //
> +  while (PeiCpuMpData->FinishedCount < (PeiCpuMpData->CpuCount - 1)) {
> +CpuPause ();
> +  }
> +  //
> +  // Enable x2APIC on BSP
> +  //
> +  SetApicMode (LOCAL_APIC_MODE_X2APIC);
> +}
> +DEBUG ((EFI_D_INFO, "APIC MODE is %d\n", GetApicMode ()));
> +//
>  // Sort BSP/Aps by CPU APIC ID in ascending order
>  //
>  SortApicId (PeiCpuMpData);
> --
> 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/PiSmmIpl: Move CommunicationBuffer from stack to global variable.

[Kinney, Michael D]

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


> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, November 24, 2015 5:00 AM
> To: edk2-de...@ml01.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>; 
> Fan, Jeff <jeff@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>
> Subject: [patch] MdeModulePkg/PiSmmIpl: Move CommunicationBuffer from stack 
> to global variable.
> 
> We had put communication buffer to Runtime memory,
> so that SMI handler can know it is not used by OS.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: "Yao, Jiewen" <jiewen@intel.com>
> Cc: "Zeng, Star" <star.z...@intel.com>
> Cc: "Fan, Jeff" <jeff@intel.com>
> Cc: "Kinney, Michael D" <michael.d.kin...@intel.com>
> ---
>  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
> b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> index c534ee3..50c3b34 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> @@ -246,6 +246,8 @@ BOOLEANmSmmLocked = FALSE;
>  EFI_PHYSICAL_ADDRESS   mSmramCacheBase;
>  UINT64 mSmramCacheSize;
> 
> +EFI_SMM_COMMUNICATE_HEADER mCommunicateHeader;
> +
>  //
>  // Table of Protocol notification and GUIDed Event notifications that the 
> SMM IPL requires
>  //
> @@ -538,21 +540,20 @@ SmmIplGuidedEventNotify (
>IN VOID   *Context
>)
>  {
> -  EFI_SMM_COMMUNICATE_HEADER  CommunicateHeader;
>UINTN   Size;
> 
>//
>// Use Guid to initialize EFI_SMM_COMMUNICATE_HEADER structure
>//
> -  CopyGuid (, (EFI_GUID *)Context);
> -  CommunicateHeader.MessageLength = 1;
> -  CommunicateHeader.Data[0] = 0;
> +  CopyGuid (, (EFI_GUID *)Context);
> +  mCommunicateHeader.MessageLength = 1;
> +  mCommunicateHeader.Data[0] = 0;
> 
>//
>// Generate the Software SMI and return the result
>//
> -  Size = sizeof (CommunicateHeader);
> -  SmmCommunicationCommunicate (, , 
> );
> +  Size = sizeof (mCommunicateHeader);
> +  SmmCommunicationCommunicate (, , 
> );
>  }
> 
>  /**
> @@ -569,7 +570,6 @@ SmmIplDxeDispatchEventNotify (
>IN VOID   *Context
>)
>  {
> -  EFI_SMM_COMMUNICATE_HEADER  CommunicateHeader;
>UINTN   Size;
>EFI_STATUS  Status;
> 
> @@ -582,20 +582,20 @@ SmmIplDxeDispatchEventNotify (
>  // Clear the buffer passed into the Software SMI.  This buffer will 
> return
>  // the status of the SMM Core Dispatcher.
>  //
> -CopyGuid (, (EFI_GUID *)Context);
> -CommunicateHeader.MessageLength = 1;
> -CommunicateHeader.Data[0] = 0;
> +CopyGuid (, (EFI_GUID *)Context);
> +mCommunicateHeader.MessageLength = 1;
> +mCommunicateHeader.Data[0] = 0;
> 
>  //
>  // Generate the Software SMI and return the result
>  //
> -Size = sizeof (CommunicateHeader);
> -SmmCommunicationCommunicate (, , 
> );
> +Size = sizeof (mCommunicateHeader);
> +SmmCommunicationCommunicate (, , 
> );
> 
>  //
>  // Return if there is no request to restart the SMM Core Dispatcher
>  //
> -if (CommunicateHeader.Data[0] != COMM_BUFFER_SMM_DISPATCH_RESTART) {
> +if (mCommunicateHeader.Data[0] != COMM_BUFFER_SMM_DISPATCH_RESTART) {
>return;
>  }
> 
> --
> 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/PiSmmCpu: Add 2 APIs in SmmCpuFeaturesLib.

[Kinney, Michael D]

Jiewen,

I recommend SmmCpuFeaturesAllocatePageTableMemory () function header comment 
block be updated clarify that the API can be called more once to allocate 
memory for page tables.  With that comment change:

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

Mike

> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, November 24, 2015 5:05 PM
> To: edk2-de...@ml01.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Fan, Jeff <jeff@intel.com>; 
> Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: [patch 1/3] UefiCpuPkg/PiSmmCpu: Add 2 APIs in SmmCpuFeaturesLib.
> 
> SmmCpuFeaturesCompleteSmmReadyToLock() is a hook point to allow
> CPU specific code to do more registers setting after
> the gEfiSmmReadyToLockProtocolGuid notification is completely processed.
> 
> SmmCpuFeaturesAllocatePageTableMemory() is an API to allow
> CPU to allocate a specific region for storing page tables.
> 
> 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/Include/Library/SmmCpuFeaturesLib.h | 33 
> ++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h 
> b/UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h
> index d1c7a8a..dba78f0 100644
> --- a/UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h
> +++ b/UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h
> @@ -363,4 +363,37 @@ SmmCpuFeaturesWriteSaveStateRegister (
>IN CONST VOID   *Buffer
>);
> 
> +/**
> +  This function is hook point called after the gEfiSmmReadyToLockProtocolGuid
> +  notification is completely processed.
> +**/
> +VOID
> +EFIAPI
> +SmmCpuFeaturesCompleteSmmReadyToLock (
> +  VOID
> +  );
> +
> +/**
> +  This API provides a method for a CPU to allocate a specific region for 
> storing page tables.
> +
> +  Allocates the number of 4KB pages of type EfiRuntimeServicesData and 
> returns a pointer to the
> +  allocated buffer.  The buffer returned is aligned on a 4KB boundary.  If 
> Pages is 0, then NULL
> +  is returned.  If there is not enough memory remaining to satisfy the 
> request, then NULL is
> +  returned.
> +
> +  This function can also return NULL if there is no preference on where the 
> page tables are allocated in SMRAM.
> +
> +  @param  Pages The number of 4 KB pages to allocate.
> +
> +  @return A pointer to the allocated buffer for page tables.
> +  @retval NULL  Fail to allocate a specific region for storing page 
> tables,
> +Or there is no preference on where the page tables are 
> allocated in SMRAM.
> +
> +**/
> +VOID *
> +EFIAPI
> +SmmCpuFeaturesAllocatePageTableMemory (
> +  IN UINTN   Pages
> +  );
> +
>  #endif
> --
> 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: Move IDT to page aligned memory.

[Kinney, Michael D]

Jiewen,

Why does IDT need to be 4KB aligned?

The IDT Base provided in the SmiException.asm and SmiException.S for IA32 and 
X64 are declared to be in .data sections.

As long as the PiSmmCpuDxeSmm driver is built with code/data sections separated 
and on 4KB boundaries, this should guarantee IDT is in 4KB page with only data.

Thanks,

Mike


> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, November 24, 2015 8:51 PM
> To: edk2-de...@ml01.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Fan, Jeff <jeff....@intel.com>; 
> Kinney, Michael D <michael.d.kin...@intel.com>
> 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: Move XD enable to ASM before paging enable.

[Kinney, Michael D]

Jiewen,

Doing 2 CPUID instructions in every SMI looks expensive.

We have global mXdSupported.  Can we change that to gXdSupported and detect 
support in driver entry and use this BOOLEAN flag in assembly code to determine 
if the MSR_EFER need to be updated?

Also, please use MSR_EFER and MSR_EFER_XD defines instead of hard coded 
0xc080 and 0x800 values.

Also, if you are not calling C function ActivateXd() anymore, this function 
should be removed from SmmProfile.c and SmmProfile.h

Thanks,

Mike

> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, November 25, 2015 12:57 AM
> To: edk2-de...@ml01.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Fan, Jeff <jeff....@intel.com>; 
> Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: [patch] UefiCpuPkg/PiSmmCpu: Move XD enable to ASM before paging 
> enable.
> 
> There might be page table set SMM data region be XD.
> So we have to enable XD before enable paging. Or #PF might be generated.
> 
> 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/SmiEntry.S   | 18 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm | 18 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c   |  7 ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S| 20 +++-
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm  | 20 +++-
>  5 files changed, 74 insertions(+), 9 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.S 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.S
> index fbaa072..7e1787c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.S
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.S
> @@ -122,6 +122,24 @@ L11:
>  orl $BIT10, %eax
>  L12:   # as cr4.PGE is not set here, 
> refresh cr3
>  movl%eax, %cr4 # in PreModifyMtrrs() to flush 
> TLB.
> +
> +#
> +# Need to test for XD support
> +#
> +movl$0x8000, %eax
> +cpuid
> +cmpl$0x8000, %eax
> +jbe L13
> +movl$0x8001, %eax
> +cpuid
> +testl   $BIT20, %edx
> +jz  L13
> +movl$0xc080, %ecx
> +rdmsr
> +orb $8,%ah # enable NXE
> +wrmsr
> +L13:
> +
>  movl%cr0, %ebx
>  orl $0x08000, %ebx # enable paging
>  movl%ebx, %cr0
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm
> index 8a12927..e6af344 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm
> @@ -128,6 +128,24 @@ gSmiCr3 DD  ?
>  or  eax, BIT10
>  @@: ; as cr4.PGE is not set here, 
> refresh cr3
>  mov cr4, eax; in PreModifyMtrrs() to flush TLB.
> +
> +;
> +; Need to test for XD support
> +;
> +mov eax, 08000h
> +cpuid
> +cmp eax, 08000h
> +jbe @f
> +mov eax, 08001h
> +cpuid
> +testedx, BIT20
> +jz  @f
> +mov ecx, 0c080h
> +rdmsr
> +or  ah, 8   ; enable NXE
> +wrmsr
> +@@:
> +
>  mov ebx, cr0
>  or  ebx, 08000h ; enable paging
>  mov cr0, ebx
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 031a5fe..26c9a0f 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -1075,13 +1075,6 @@ SmiRendezvous (
>InitializeSpinLock (>CpuData[CpuIndex].Busy);
>  }
> 
> -//
> -// Try to enable NX
> -//
> -if (mXdSupported) {
> -  ActivateXd ();
> -}
> -
>  if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
>ActivateSmmProfile (CpuIndex);
>  }
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
> index b488b74..1d40819 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
> @@ -139,9 +139,27 @@ ASM_PFX(gSmiCr3):.space  4
>  call Base # push return address for retf 
> later
>  Base:
>  addl$(LongMode - Base), (%rsp)  # offset for far retf, seg is the 
> 1st arg
> +
> +#
> +# Need to test for XD support
> +#
> +movl$0x

Re: [edk2] [PATCH v2 2/2] UefiCpuPkg/CpuS3DataDxe: Add module to initialize ACPI_CPU_DATA for S3

[Kinney, Michael D]

Laszlo,

Thanks for the feedback and the testing!

I have made the updates you suggested in this series except for removing the 
lines that initialize the RegisterTable fields.  I left those there to make it 
easier for CPU/Platform package that needs to use this module as a starting 
point for a custom version.

This series has been committed, so it is now available for use with your OVMF 
SMM v5 series.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Wednesday, November 25, 2015 3:04 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-de...@ml01.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Fan, Jeff <jeff@intel.com>
> Subject: Re: [edk2] [PATCH v2 2/2] UefiCpuPkg/CpuS3DataDxe: Add module to 
> initialize ACPI_CPU_DATA for S3
> 
> On 11/25/15 00:47, Michael Kinney wrote:
> > 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.
> >
> > This patch series is in response to the OvmfPkg patch series from
> > Laszlo Ersek that enables SMM on OVMF.  The v4 version of the patch
> > series from Laszlo includes an OVMF specific CPU module to initialize
> > the ACPI_CPU_DATA structure.
> >
> > This proposed patch series replaces the patches listed below.
> >
> > [PATCH v4 27/41] OvmfPkg:
> >   add skeleton QuarkPort/CpuS3DataDxe
> >
> > [PATCH v4 28/41] OvmfPkg:
> >   QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.StartupVector
> >
> > [PATCH v4 29/41] OvmfPkg:
> >   QuarkPort/CpuS3DataDxe: handle IDT, GDT and MCE in ACPI_CPU_DATA
> >
> > [PATCH v4 30/41] OvmfPkg:
> >   QuarkPort/CpuS3DataDxe: handle StackAddress and StackSize
> >
> > [PATCH v4 31/41] OvmfPkg:
> >   import CpuConfigLib header from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
> >
> > [PATCH v4 32/41] OvmfPkg:
> >   QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.NumberOfCpus
> >
> > [PATCH v4 33/41] OvmfPkg:
> >   QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.MtrrTable
> >
> > [PATCH v4 34/41] OvmfPkg:
> >   QuarkPort/CpuS3DataDxe: handle register tables in ACPI_CPU_DATA
> >
> > [PATCH v4 35/41] OvmfPkg:
> >   port CpuS3DataDxe to X64
> >
> > [PATCH v4 36/41] OvmfPkg:
> >   build QuarkPort/CpuS3DataDxe for -D SMM_REQUIRE
> >
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Cc: "Yao, Jiewen" <jiewen@intel.com>
> > Cc: "Fan, Jeff" <jeff@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
> > ---
> >  UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c  | 271 
> > +++
> >  UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf |  64 
> >  UefiCpuPkg/UefiCpuPkg.dsc|   1 +
> >  3 files changed, 336 insertions(+)
> >  create mode 100644 UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> >  create mode 100644 UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> 
> (1) The commit message looks great, thank you very much for the references.
> 
> A small request: please mark, under "port CpuS3DataDxe to X64" (i.e.,
> [PATCH v4 35/41]), that that patch was originally authored by Paolo Bonzini.
> 
> There's no need to submit a v3 of this series just because of this; it
> can be fixed up before committing the patch.
> 
> >
> > diff --git a/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c 
> > b/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> > new file mode 100644
> > index 000..7cf923d
> > --- /dev/null
> > +++ b/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> > @@ -0,0 +1,271 @@
> > +/** @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 Protoco

Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

[Kinney, Michael D]

Laszlo,

Comments below.

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, November 23, 2015 4:34 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-de...@ml01.01.org
> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
> Subject: Re: [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM 
> during PEI
> 
> On 11/21/15 07:36, Kinney, Michael D wrote:
> > Laszlo,
> >
> > Minor comments included below.  I know from later items in this thread that 
> > SMM_COMMUNICATE has already been removed in
> your local branch.
> >
> > Reviewed-by: Michael Kinney <michael.d.kin...@intel.com>
> 
> Thank you. I've picked this up now.
> 
> As far as I can see your comments, they are very similar to those you made 
> for patch #8 (sorry, I read your feedback to patch #8 first);
> my followup is identical:
> - I've now listed the header file in [Sources],
> - I've fixed up the PRODUCES comment for the PPI GUID,
> - I'd like to stick with STATIC under OvmfPkg,

Ok.

> - I can move the definition of the global variable to the top, remove
>   its initializer, and assign the members in the driver entry point
>   instead, if you'd like me to.

You don't have to assign members in driver entry point.  You can still do it in 
global variable.  You just need function prototype before reference in global.

> 
> Thanks!
> Laszlo
> 
> >
> > Mike
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Tuesday, November 3, 2015 1:01 PM
> >> To: edk2-de...@ml01.01.org
> >> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Justen, Jordan L
> >> <jordan.l.jus...@intel.com>
> >> Subject: [PATCH v4 07/41] OvmfPkg: add PEIM for providing
> >> TSEG-as-SMRAM during PEI
> >>
> >> "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the
> >> library instance that implements the LockBoxLib library class with
> >> SMRAM access for the PEI phase.
> >>
> >> Introduce a PEIM that produces the EFI_PEI_SMM_COMMUNICATION_PPI and
> >> PEI_SMM_ACCESS_PPI interfaces, enabling SmmLockBoxPeiLib to work.
> >>
> >> Said library instance can parse and access LockBox data itself
> >> (without additional LockBox drivers) if the
> >> EFI_PEI_SMM_COMMUNICATION_PPI.Communicate() function returns
> >> EFI_NOT_STARTED to it. However it requires that
> >> EFI_PEI_SMM_COMMUNICATION_PPI exist at least. Also,
> >> PEI_SMM_ACCESS_PPI must exist and work.
> >>
> >> The load / installation order of S3Resume2Pei and SmmAccessPei is
> >> indifferent. SmmAccessPei produces the GUIDed HOB during its
> >> installation (which happens during PEI), but S3Resume2Pei accesses
> >> the HOB only when the DXE IPL calls its S3RestoreConfig2 PPI member, as 
> >> last act of PEI.
> >>
> >> MCH_SMRAM_D_LCK and MCH_ESMRAMC_T_EN are masked out the way they are,
> >> in
> >> SmmAccessPeiEntryPoint() and SmramAccessOpen() respectively, in order
> >> to prevent VS20xx from warning about the (otherwise fully
> >> intentional) truncation in the UINT8 casts. (Warnings reported by
> >> Michael Kinney.)
> >>
> >> 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: Laszlo Ersek <ler...@redhat.com>
> >> ---
> >>
> >> Notes:
> >> v3:
> >> - update bit-neg expressions to silence VS20xx warnings [Mike]
> >>
> >>  OvmfPkg/OvmfPkgIa32.dsc|   6 +
> >>  OvmfPkg/OvmfPkgIa32X64.dsc |   6 +
> >>  OvmfPkg/OvmfPkgX64.dsc |   6 +
> >>  OvmfPkg/OvmfPkgIa32.fdf|   3 +
> >>  OvmfPkg/OvmfPkgIa32X64.fdf |   3 +
> >>  OvmfPkg/OvmfPkgX64.fdf |   3 +
> >>  OvmfPkg/SmmAccess/SmmAccessPei.inf |  70 +++
> >> OvmfPkg/SmmAccess/SmramInternal.h  |  89 
> >>  OvmfPkg/SmmAccess/SmmAccessPei.c   | 446 
> >>  OvmfPkg/SmmAccess/SmramInternal.c  | 188 +
> >>  10 files changed, 820 insertions(+)
> >>
> >> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index
> >> c6850ff..0b729ca 100644
> >> --- a/OvmfPkg/OvmfPkgIa32.dsc
> >> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> >> @@ -445,6 +445,12 @@ [Components]
> >>  
> >>