mirror_edk2.git
3 years agoIntelFsp2Pkg: Add missing modules in Package DSC
Liming Gao [Fri, 8 Jul 2016 14:22:51 +0000 (22:22 +0800)]
IntelFsp2Pkg: Add missing modules in Package DSC

Package DSC is used to verify the module source build.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Giri Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoIntelFsp2WrapperPkg: Add missing modules in Package DSC
Liming Gao [Fri, 8 Jul 2016 14:22:26 +0000 (22:22 +0800)]
IntelFsp2WrapperPkg: Add missing modules in Package DSC

Package DSC is used to verify the module source build.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Giri Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoIntelFsp2WrapperPkg SecFspWrapperPlatformSecLibSample:Update code to pass build
Liming Gao [Mon, 11 Jul 2016 02:24:16 +0000 (10:24 +0800)]
IntelFsp2WrapperPkg SecFspWrapperPlatformSecLibSample:Update code to pass build

1. Update its library class to PlatformSecLib
2. Update source code to refer to the matched header file

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Giri Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoVlv2TbltDevicePkg/PlatformInitPei: Explicit call to dump MTRR Setting
Jeff Fan [Tue, 19 Jul 2016 00:50:08 +0000 (08:50 +0800)]
Vlv2TbltDevicePkg/PlatformInitPei: Explicit call to dump MTRR Setting

Mtrr library instance removed MtrrDebugPrintAllMtrrs() from MtrrSetAllMtrrs() to
make MP safe. We need to explicitly call MtrrDebugPrintAllMtrrs() to dump MTRR
setting.

CC: David Wei <david.wei@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: David Wei <david.wei@intel.com>
3 years agoUefiCpuPkg/CpuDxe: StartupAllAPs in parallel mode
Jeff Fan [Fri, 1 Jul 2016 07:52:40 +0000 (15:52 +0800)]
UefiCpuPkg/CpuDxe: StartupAllAPs in parallel mode

SetMemoryAttributes() will sync BSP's MTRRs settings to all APs by StartupAllAPs
service in serial mode. It may caused much performance impact if there are too
much processors in system. This update is to invoke StartupAllAps in parallel
mode. IA32 SDM does suggest to program MTRRs in parallel mode.

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
3 years agoUefiCpuPkg/MtrrLib: Add notes for usage by BSP/APs
Jeff Fan [Tue, 19 Jul 2016 00:41:57 +0000 (08:41 +0800)]
UefiCpuPkg/MtrrLib: Add notes for usage by BSP/APs

Except for MtrrSetAllMtrrs(), others services are not suggested to be invoked by
APs because they are not necessary and may invoke DEBUG() to dump MTRR setting.

Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed: Laszlo Ersek <lersek@redhat.com>

3 years agoUefiCpuPkg/MtrrLib: Remove MTRRs display from MtrrSetAllMtrrs()
Jeff Fan [Tue, 12 Jul 2016 14:08:58 +0000 (22:08 +0800)]
UefiCpuPkg/MtrrLib: Remove MTRRs display from MtrrSetAllMtrrs()

MtrrSetAllMtrrs() maybe used by APs to sync BSP's MTRR settings. BSP's MTRR
setting should be displayed if EFI_D_CACHE flag is set when MTRR updated. In
MtrrSetAllMtrrs(), it's not necessary to display MTRR setting again due to the
MTRR settings should be always same among BSP/APs. This updating could avoid
APs output MTRR setting at the same time and make display message corrupted.

Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
3 years agoShellPkg: Fix echo to support displaying special characters
Ruiyu Ni [Mon, 18 Jul 2016 09:50:20 +0000 (17:50 +0800)]
ShellPkg: Fix echo to support displaying special characters

Run 'echo -t' without the patch will get the result:
  echo: Unknown flag - '-t'
  The expected result is to display '-t' literally.
  This patch adds special handle for 'echo'. 'echo' will not use the
  general parameter parsing library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg: Add Shell[Get|Set]RawCmdLine to ShellCommandLib
Ruiyu Ni [Mon, 18 Jul 2016 09:46:59 +0000 (17:46 +0800)]
ShellPkg: Add Shell[Get|Set]RawCmdLine to ShellCommandLib

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg: Move FindFirstCharacter/GetNextParameter to ShellCommandLib
Ruiyu Ni [Mon, 18 Jul 2016 10:06:33 +0000 (18:06 +0800)]
ShellPkg: Move FindFirstCharacter/GetNextParameter to ShellCommandLib

And add Shell prefix to the two library APIs.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/ShellCommandLib.h: Formalize EOL
Ruiyu Ni [Mon, 18 Jul 2016 10:01:35 +0000 (18:01 +0800)]
ShellPkg/ShellCommandLib.h: Formalize EOL

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/UefiShellCommandLib.c: Formalize EOL
Ruiyu Ni [Mon, 18 Jul 2016 02:48:40 +0000 (10:48 +0800)]
ShellPkg/UefiShellCommandLib.c: Formalize EOL

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg: Fix VS2010/2012 build failure
Ruiyu Ni [Tue, 19 Jul 2016 02:26:19 +0000 (10:26 +0800)]
ShellPkg: Fix VS2010/2012 build failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
3 years agoOvmfPkg/PlatformPei: silence X64 VS2015x86 warning
Laszlo Ersek [Thu, 14 Jul 2016 15:59:44 +0000 (17:59 +0200)]
OvmfPkg/PlatformPei: silence X64 VS2015x86 warning

VS2015x86 reports the following warning for
"OvmfPkg/PlatformPei/MemDetect.c":

> MemDetect.c(357): error C2220: warning treated as error - no 'object'
>                   file generated
> MemDetect.c(357): warning C4244: '=': conversion from 'UINT64' to
>                   'UINT32', possible loss of data

LowerMemorySize is first assigned from GetSystemMemorySizeBelow4gb(),
which returns UINT32. Change the type of LowerMemorySize accordingly.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoOvmfPkg/PciHostBridgeLib: silence IA32 VS2015x86 warnings
Laszlo Ersek [Thu, 14 Jul 2016 15:34:38 +0000 (17:34 +0200)]
OvmfPkg/PciHostBridgeLib: silence IA32 VS2015x86 warnings

When compiling "OvmfPkg\Library\PciHostBridgeLib\XenSupport.c" for IA32,
the VS2015x86 compiler emits the following:

> XenSupport.c(41): error C2220: warning treated as error - no 'object'
>                                file generated
> XenSupport.c(41): warning C4244: 'function': conversion from 'UINT64' to
>                                  'UINTN', possible loss of data
> XenSupport.c(48): warning C4244: 'function': conversion from 'UINT64' to
>                                  'UINTN', possible loss of data
> XenSupport.c(49): warning C4244: 'function': conversion from 'UINT64' to
>                                  'UINTN', possible loss of data
> XenSupport.c(50): warning C4244: 'function': conversion from 'UINT64' to
>                                  'UINTN', possible loss of data
> XenSupport.c(222): warning C4244: 'function': conversion from 'UINT64'
>                                   to 'UINTN', possible loss of data
> XenSupport.c(241): warning C4244: 'function': conversion from 'UINT64'
>                                   to 'UINTN', possible loss of data

PciLib functions take UINTN addresses that were encoded with the
PCI_LIB_ADDRESS() macro. We carry addresses from the macro invocations to
the function calls in two UINT64 variables however. This loses no data,
but it alerts VS2015x86. Change the variable types to UINTN.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoUefiCpuPkg/PiSmmCpuDxeSmm: remove superfluous ENDs from NASM source
Laszlo Ersek [Thu, 14 Jul 2016 14:36:37 +0000 (16:36 +0200)]
UefiCpuPkg/PiSmmCpuDxeSmm: remove superfluous ENDs from NASM source

Commits 28ee5816465b1 and 246cd9085f806 added these ENDs as part of the
manual conversion from *.asm files. However, the ENDs makes no sense for
NASM. Although they don't break the build, NASM complains about them:

  label alone on a line without a colon might be in error

(This NASM warning category dates back to NASM 0.95, commit
6768eb71d8deb.)

Remove the ENDs.

Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools/tools_def.template: bump minimum required NASM versions
Laszlo Ersek [Thu, 14 Jul 2016 11:29:10 +0000 (13:29 +0200)]
BaseTools/tools_def.template: bump minimum required NASM versions

NASM had been unable to assemble segment register operations before the
following git commit:

  http://repo.or.cz/nasm.git/commitdiff/21d4ccc3c338

That commit was first released in NASM 2.10:

  http://repo.or.cz/nasm.git/commitdiff/ff62f33da0a2

This makes NASM 2.07 unusable for edk2 in general, because now we have a
lot of X64 assembly code that works with segment registers. For example
in:

  UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm

Bump the minimum required version to 2.10, for use with GCC toolchains.

Furthermore, list NASM 2.12.01 as a requirement for all other toolchains.
In particular, for source level debugging, VS20xx requires CodeView 8
debug symbols, and only NASM 2.12.01 and later produce those. (Suggested
by Liming, Mike, and Andrew.)

Cc: Andrew Fish <afish@apple.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/14612
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg/PciHostBridgeDxe: fix Ia32 GCC44 build error
Laszlo Ersek [Thu, 14 Jul 2016 09:53:50 +0000 (11:53 +0200)]
MdeModulePkg/PciHostBridgeDxe: fix Ia32 GCC44 build error

> cc1: warnings being treated as errors
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c:
>   In function 'GetProposedResources':
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c:1388:
>   error: integer constant is too large for 'long' type

Append a ULL suffix to the replacement text of PCI_RESOURCE_LESS that is
aligned with the style of the EFI_RESOURCE_SATISFIED and
EFI_RESOURCE_NOT_SATISFIED macros.

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoIntelFsp2Pkg BaseFspPlatformLib: Remove Boot Loader tempram Migration
Satya Yarlagadda [Wed, 13 Jul 2016 13:02:46 +0000 (21:02 +0800)]
IntelFsp2Pkg BaseFspPlatformLib: Remove Boot Loader tempram Migration

In FSP2.0, Boot loader should migrate its temp ram before
calling the tempramexit API to tear down the tempram. so, we don't need the
function to migrate the BL TempRam in the IntelFsp2Pkg.

Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Satya Yarlagadda <satya.p.yarlagadda@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoShellPkg/Ping6: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 09:43:47 +0000 (17:43 +0800)]
ShellPkg/Ping6: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/Ifconfig6: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 09:41:19 +0000 (17:41 +0800)]
ShellPkg/Ifconfig6: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/UefiShellLib.c: Handle memory allocation failure
Ruiyu Ni [Thu, 14 Jul 2016 05:15:34 +0000 (13:15 +0800)]
ShellPkg/UefiShellLib.c: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/IfConfig: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 09:39:58 +0000 (17:39 +0800)]
ShellPkg/IfConfig: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/UefiShellLib: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 09:39:37 +0000 (17:39 +0800)]
ShellPkg/UefiShellLib: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/Mv: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 09:38:51 +0000 (17:38 +0800)]
ShellPkg/Mv: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/Cp: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 09:38:24 +0000 (17:38 +0800)]
ShellPkg/Cp: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/Cd: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 09:38:05 +0000 (17:38 +0800)]
ShellPkg/Cd: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/If: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 07:47:16 +0000 (15:47 +0800)]
ShellPkg/If: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/For: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 07:45:08 +0000 (15:45 +0800)]
ShellPkg/For: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/DrvDiag: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 07:44:43 +0000 (15:44 +0800)]
ShellPkg/DrvDiag: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/DrvCfg: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 07:44:23 +0000 (15:44 +0800)]
ShellPkg/DrvCfg: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/DevTree: Handle memory allocation failure
Ruiyu Ni [Wed, 13 Jul 2016 07:43:55 +0000 (15:43 +0800)]
ShellPkg/DevTree: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/Edit: Handle memory allocation failure
Ruiyu Ni [Tue, 12 Jul 2016 10:13:41 +0000 (18:13 +0800)]
ShellPkg/Edit: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/LoadPciRom: Handle memory allocation failure
Ruiyu Ni [Tue, 12 Jul 2016 10:06:58 +0000 (18:06 +0800)]
ShellPkg/LoadPciRom: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/EfiDecompress: Handle memory allocation failure
Ruiyu Ni [Tue, 12 Jul 2016 10:00:01 +0000 (18:00 +0800)]
ShellPkg/EfiDecompress: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/EfiCompress: Handle memory allocation failure
Ruiyu Ni [Tue, 12 Jul 2016 09:52:41 +0000 (17:52 +0800)]
ShellPkg/EfiCompress: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/DMem: Handle memory allocation failure
Ruiyu Ni [Tue, 12 Jul 2016 09:39:43 +0000 (17:39 +0800)]
ShellPkg/DMem: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/UefiShellCommandLib.c: Handle memory allocation failure
Ruiyu Ni [Tue, 12 Jul 2016 09:38:06 +0000 (17:38 +0800)]
ShellPkg/UefiShellCommandLib.c: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/ConsistMapping.c: Handle memory allocation failure
Ruiyu Ni [Tue, 12 Jul 2016 07:01:17 +0000 (15:01 +0800)]
ShellPkg/ConsistMapping.c: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/UefiShellBcfgCommandLib: Handle memory allocation failure
Ruiyu Ni [Tue, 12 Jul 2016 05:56:04 +0000 (13:56 +0800)]
ShellPkg/UefiShellBcfgCommandLib: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/UefiHandleParsingLib.c: Handle memory allocation failure
Ruiyu Ni [Tue, 12 Jul 2016 05:51:54 +0000 (13:51 +0800)]
ShellPkg/UefiHandleParsingLib.c: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/Dp: Handle memory allocation failure
Ruiyu Ni [Tue, 12 Jul 2016 05:42:59 +0000 (13:42 +0800)]
ShellPkg/Dp: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/ShellProtocol.c: Handle memory allocation failure
Ruiyu Ni [Thu, 14 Jul 2016 07:04:38 +0000 (15:04 +0800)]
ShellPkg/ShellProtocol.c: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/ShellAddEnvVarToList: Handle memory allocation failure
Ruiyu Ni [Mon, 11 Jul 2016 05:56:49 +0000 (13:56 +0800)]
ShellPkg/ShellAddEnvVarToList: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/IsVolatileEnv: Handle memory allocation failure
Ruiyu Ni [Fri, 8 Jul 2016 07:18:14 +0000 (15:18 +0800)]
ShellPkg/IsVolatileEnv: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/Shell.c: Handle memory allocation failure
Ruiyu Ni [Fri, 8 Jul 2016 06:47:48 +0000 (14:47 +0800)]
ShellPkg/Shell.c: Handle memory allocation failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoMdeModulePkg: Fix bug in TCP which not sending out ACK in certain circumstance.
Fu Siyuan [Tue, 12 Jul 2016 01:47:58 +0000 (09:47 +0800)]
MdeModulePkg: Fix bug in TCP which not sending out ACK in certain circumstance.

Consider the situation as shown in below chart. The last ACK message has
acknowledged the Tcb->RcvWl2, and all the segments until Tcb->RcvNxt have
been received by TCP driver. The Tcb->RcvNxt is not acknowledged due to the
delayed ACK. In this case an incoming segment (Seg->Seq, Seg->End) should
not be accepted by TCP driver, and an immediate ACK is required.

Current TcpSeqAcceptable() thought it’s an acceptable segment incorrectly, it
continues the TcpInput() process instead of sending out an ACK and droping the
segment immediately.

Tcb->RcvWl2                       Tcb->RcvNxt        Tcb->RcvWl2 + Tcb->RcvWnd
        Seg->Seq       Seg->End         |                          |
    |     |               |             |                          |
 ---+-----+---------------+-------------+--------------------------+-----------
           <income segment>             <----Acceptable Range--- -->

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-By: Eugene Cohen <eugene@hp.com>
Reviewed-By: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-By: Ye Ting <ting.ye@intel.com>
3 years agoNetworkPkg: Fix bug in TCP which not sending out ACK in certain circumstance.
Fu Siyuan [Fri, 8 Jul 2016 03:59:13 +0000 (11:59 +0800)]
NetworkPkg: Fix bug in TCP which not sending out ACK in certain circumstance.

Consider the situation as shown in below chart. The last ACK message has
acknowledged the Tcb->RcvWl2, and all the segments until Tcb->RcvNxt have
been received by TCP driver. The Tcb->RcvNxt is not acknowledged due to the
delayed ACK. In this case an incoming segment (Seg->Seq, Seg->End) should
not be accepted by TCP driver, and an immediate ACK is required.

Current TcpSeqAcceptable() thought it’s an acceptable segment incorrectly, it
continues the TcpInput() process instead of sending out an ACK and droping the
segment immediately.

Tcb->RcvWl2                       Tcb->RcvNxt        Tcb->RcvWl2 + Tcb->RcvWnd
        Seg->Seq       Seg->End         |                          |
    |     |               |             |                          |
 ---+-----+---------------+-------------+--------------------------+-----------
           <income segment>             <----Acceptable Range--- -->

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-By: Eugene Cohen <eugene@hp.com>
Reviewed-By: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-By: Ye Ting <ting.ye@intel.com>
3 years agoBaseTools: Fix a bug for FixedPcd value generation in AutoGen file
Yonghong Zhu [Wed, 13 Jul 2016 09:00:03 +0000 (17:00 +0800)]
BaseTools: Fix a bug for FixedPcd value generation in AutoGen file

If the library is listed in [Components] section for build only, its
used FixedPcd Value is not generated into AutoGen code. This patch
cover this case to generate the FixedPcd Value in AutoGen file.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoShellPkg: Fix issue about Ifconfig6 -r command.
Zhang Lubo [Thu, 14 Jul 2016 02:31:44 +0000 (10:31 +0800)]
ShellPkg: Fix issue about Ifconfig6 -r command.

Follow the Shell Spec, when the interface name is Specified,
we need to refresh the Ipv6 configuration.

Cc: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Reviewed-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
Reviewed-by: Sriram Subramanian <sriram-s@hpe.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-By: Wu Jiaxin <jiaxin.wu@intel.com>
3 years agoOvmfPkg/PlatformPei: program MSR_IA32_FEATURE_CONTROL from fw_cfg
Laszlo Ersek [Thu, 7 Jul 2016 13:02:11 +0000 (15:02 +0200)]
OvmfPkg/PlatformPei: program MSR_IA32_FEATURE_CONTROL from fw_cfg

Under certain circumstances, QEMU exposes the "etc/msr_feature_control"
fw_cfg file, with a 64-bit little endian value. The firmware is supposed
to write this value to MSR_IA32_FEATURE_CONTROL (0x3a), on all processors,
on the normal and the S3 resume boot paths.

Utilize EFI_PEI_MPSERVICES_PPI to implement this feature.

Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Fixes: https://github.com/tianocore/edk2/issues/97
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg: include UefiCpuPkg/CpuMpPei
Laszlo Ersek [Wed, 6 Jul 2016 16:09:16 +0000 (18:09 +0200)]
OvmfPkg: include UefiCpuPkg/CpuMpPei

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

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

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

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

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

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

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

Jeff recommended to resolve CpuExceptionHandlerLib to
PeiCpuExceptionHandlerLib for all PEIMs:

- http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477

Since at the moment we have no resolution in place that would cover this
for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]),
it's easy to do.

Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySize
Laszlo Ersek [Tue, 12 Jul 2016 20:23:32 +0000 (22:23 +0200)]
OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySize

No module in OvmfPkg uses these PCDs any longer.

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

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

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

Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3
Laszlo Ersek [Tue, 12 Jul 2016 22:52:54 +0000 (00:52 +0200)]
OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3

Move the permanent PEI memory for the S3 resume boot path to the top of
the low RAM (just below TSEG if the SMM driver stack is included in the
build). The new size is derived from CpuMpPei's approximate memory demand.

Save the base address and the size in new global variables, regardless of
the boot path. On the normal boot path, use these variables for covering
the area with EfiACPIMemoryNVS type memory.

PcdS3AcpiReservedMemoryBase and PcdS3AcpiReservedMemorySize become unused
in PlatformPei; remove them.

Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/PlatformPei: create one memory HOB at S3 resume too, for CpuMpPei
Laszlo Ersek [Thu, 7 Jul 2016 07:29:12 +0000 (09:29 +0200)]
OvmfPkg/PlatformPei: create one memory HOB at S3 resume too, for CpuMpPei

CpuMpPei will have to place the AP startup vector in memory under 1MB. For
this, CpuMpPei borrows memory under 1MB, but it needs a memory resource
descriptor HOB to exist there even on the S3 resume path (see the
GetWakeupBuffer() function). Produce such a HOB as an exception on the S3
resume path.

CpuMpPei is going be dispatched no earlier than PlatformPei, because
CpuMpPei has a depex on gEfiPeiMemoryDiscoveredPpiGuid, and PlatformPei
calls PublishSystemMemory().

Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoUefiCpuPkg/PiSmmCpuDxeSmm: Clean up CheckFeatureSupported()
Jeff Fan [Sat, 2 Jul 2016 04:01:02 +0000 (12:01 +0800)]
UefiCpuPkg/PiSmmCpuDxeSmm: Clean up CheckFeatureSupported()

Removed EFIAPI and parameter from CheckFeatureSupported() and removed
CheckProcessorFeature() totally.

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoUefiCpuPkg/PiSmmCpuDxeSmm: Check XD/BTS features in SMM relocation
Jeff Fan [Sat, 2 Jul 2016 03:55:58 +0000 (11:55 +0800)]
UefiCpuPkg/PiSmmCpuDxeSmm: Check XD/BTS features in SMM relocation

CheckProcessorFeature() invokes MpService->StartupAllAps() to detect
XD/BTS features on normal boot path. It's not necessary and may cause
performance impact, because INIT-SIPI-SIPI must be sent to APs if APs
are in hlt-loop mode. XD/BTS feature detection is moved to
SmmInitHandler() in SMM relocation during normal boot path.

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoUefiCpuPkg/PiSmmCpuDxeSmm: Add SMM S3 boot flag
Jeff Fan [Sat, 2 Jul 2016 03:08:04 +0000 (11:08 +0800)]
UefiCpuPkg/PiSmmCpuDxeSmm: Add SMM S3 boot flag

It will be set to TRUE during S3 resume.

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoUefiCpuPkg/PiSmmCpuDxeSmm: Add MemoryMapped in SetProcessorRegister()
Jeff Fan [Wed, 29 Jun 2016 01:00:13 +0000 (09:00 +0800)]
UefiCpuPkg/PiSmmCpuDxeSmm: Add MemoryMapped in SetProcessorRegister()

REGISTER_TYPE in UefiCpuPkg/Include/AcpiCpuData.h defines a MemoryMapped
enum value.  However support for the MemoryMapped enum is missing from
the implementation of SetProcessorRegister().  This patch adds support
for MemoryMapped type SetProcessorRegister().

One spin lock is added to avoid potential conflict when multiple processor
update the same memory space.

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoUefiCpuPkg/PiSmmCpuDxeSmm: Remove duplicate aligned buffer on S3 path
Jeff Fan [Mon, 27 Jun 2016 07:41:50 +0000 (15:41 +0800)]
UefiCpuPkg/PiSmmCpuDxeSmm: Remove duplicate aligned buffer on S3 path

InitializeMpSyncData() invokes InitializeSmmCpuSemaphores() to allocate an
aligned buffer for all locks and semaphores. However, this function is
invoked on S3 resume path again to reset mSmmMpSyncData. It causes
an additional aligned buffer to be allocated.

This update moves InitializeSmmCpuSemaphores() into
InitializeMpServiceData() that is only invoked on normal boot.
InitializeMpSyncData() is updated to reset the locks/semaphore in
mSmmMpSyncData.

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmPlatformPkg/ArmJuno: Correct AXI->PCIe translation comments
Jeremy Linton [Thu, 14 Jul 2016 13:58:30 +0000 (08:58 -0500)]
ArmPlatformPkg/ArmJuno: Correct AXI->PCIe translation comments

The AXI<->PCIe translation comments are out of date with
respect to the code. In the first case the AXI master port
is incorrectly called a slave. In the second case the the
translation direction indicated for the slave port is the
wrong direction.

Correct both of these comments to reflect what the code is
doing.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoArmPlatformPkg/ArmJuno: fix Juno PIO host bridge mapping
Jeremy Linton [Thu, 14 Jul 2016 13:58:29 +0000 (08:58 -0500)]
ArmPlatformPkg/ArmJuno: fix Juno PIO host bridge mapping

The Juno PIO mapping is 8M, so it should be using a 32-bit
PIO address translation. Further, PIO addresses should start
at 0 and be translated to/from the ARM MMIO region.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoSecurityPkg DxeTpmMeasureBootLib: Add comments in TcgMeasurePeImage()
Liming Gao [Wed, 13 Jul 2016 12:28:19 +0000 (20:28 +0800)]
SecurityPkg DxeTpmMeasureBootLib: Add comments in TcgMeasurePeImage()

The input PeImage in TcgMeasurePeImage() has been checked.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
3 years agoSecurityPkg DxeImageVerificationLib: Add comments in HashPeImage()
Liming Gao [Wed, 13 Jul 2016 12:28:18 +0000 (20:28 +0800)]
SecurityPkg DxeImageVerificationLib: Add comments in HashPeImage()

The input PeImage in HashPeImage() has been checked.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
3 years agoSecurityPkg Tcg2Dxe: Add check for the PE/COFF image
Liming Gao [Wed, 13 Jul 2016 12:28:17 +0000 (20:28 +0800)]
SecurityPkg Tcg2Dxe: Add check for the PE/COFF image

Use BasePeCoffLib PeCoffLoaderGetImageInfo() to check the PE/COFF image.

In V2, add specific ImageRead() to make sure the PE/COFF image content
read is within the image buffer.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
3 years agoSecurityPkg TrEEDxe: Add check for the PE/COFF image.
Liming Gao [Wed, 13 Jul 2016 12:28:16 +0000 (20:28 +0800)]
SecurityPkg TrEEDxe: Add check for the PE/COFF image.

Use BasePeCoffLib PeCoffLoaderGetImageInfo() to check the PE/COFF image.

In V2, add specific ImageRead() to make sure the PE/COFF image content
read is within the image buffer.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
3 years agoSecurityPkg SecureBootConfigDxe: Add check for the external PE/COFF image.
Liming Gao [Wed, 13 Jul 2016 12:28:15 +0000 (20:28 +0800)]
SecurityPkg SecureBootConfigDxe: Add check for the external PE/COFF image.

Use BasePeCoffLib PeCoffLoaderGetImageInfo() to check the PE/COFF image.

In V2, add specific ImageRead() to make sure the PE/COFF image content
read is within the image buffer.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
3 years agoIntelFsp2WrapperPkg: Remove unused header files from Fspm and Fsps WrapperPeim
Liming Gao [Thu, 14 Jul 2016 02:16:29 +0000 (10:16 +0800)]
IntelFsp2WrapperPkg: Remove unused header files from Fspm and Fsps WrapperPeim

PlatformSecLib.h is not used and removed.

Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoMdePkg/BaseSynchronizationLib: spin lock alignment is 32 at least
Jeff Fan [Tue, 12 Jul 2016 03:10:27 +0000 (11:10 +0800)]
MdePkg/BaseSynchronizationLib: spin lock alignment is 32 at least

Some processor may return small cache line size, we should return 32 bytes at
least for spin lock alignment.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoUefiCpuPkg/CpuMpPei: Remove PmodeOffset and LmodeOffset
Jeff Fan [Tue, 12 Jul 2016 00:49:33 +0000 (08:49 +0800)]
UefiCpuPkg/CpuMpPei: Remove PmodeOffset and LmodeOffset

Remove Pmode(Entry)Offset/Lmode(Entry)Offset and use unified Mode(Entry)Offset
to clean up the definition of MP_ASSEMBLY_ADDRESS_MAP and MP_CPU_EXCHANGE_INFO.

Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Giri Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoUefiCpuPkg/CpuMpPei: Remove un-used variables and functions
Jeff Fan [Mon, 11 Jul 2016 11:52:00 +0000 (19:52 +0800)]
UefiCpuPkg/CpuMpPei: Remove un-used variables and functions

Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Giri Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoUefiCpuPkg/CpuMpPei: Do not load new GDT table
Jeff Fan [Mon, 11 Jul 2016 11:46:36 +0000 (19:46 +0800)]
UefiCpuPkg/CpuMpPei: Do not load new GDT table

Do not load the new GDT table and just to use the exiting BSP's GDT table set up
by SEC phase.

Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Giri Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoUefiCpuPkg/CpuMpPei/X64: Use CodeSegment and DataSegment fields
Jeff Fan [Mon, 11 Jul 2016 11:40:05 +0000 (19:40 +0800)]
UefiCpuPkg/CpuMpPei/X64: Use CodeSegment and DataSegment fields

Using CodeSegment and DataSegment fields in ExchangeInfo instead of the hardcode
MACROs for x64 arch. Switch AP from real mode to long mode directly, so needn't
the CS/DS of protected mode.

Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Giri Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoUefiCpuPkg/CpuMpPei/X64: Remove hard code CPU BIST value
Jeff Fan [Mon, 11 Jul 2016 06:35:26 +0000 (14:35 +0800)]
UefiCpuPkg/CpuMpPei/X64: Remove hard code CPU BIST value

Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Giri Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoUefiCpuPkg/CpuMpPei/Ia32: Use CodeSegment and DataSegment fields
Jeff Fan [Mon, 11 Jul 2016 05:21:10 +0000 (13:21 +0800)]
UefiCpuPkg/CpuMpPei/Ia32: Use CodeSegment and DataSegment fields

Using CodeSegment and DataSegment fields in ExchangeInfo instead of the hardcode
MACROs.

Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Giri Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoUefiCpuPkg/CpuMpPei: Add CodeSegment and DataSegment fields
Jeff Fan [Mon, 11 Jul 2016 05:08:06 +0000 (13:08 +0800)]
UefiCpuPkg/CpuMpPei: Add CodeSegment and DataSegment fields

Added CodeSegment and DataSegment fields in MP_CPU_EXCHANGE_INFO. They are set
to the values of current BSP's CS and DS.

Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Giri Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoBaseTools: Update the FV region name as upper letter
Yonghong Zhu [Mon, 11 Jul 2016 07:52:09 +0000 (15:52 +0800)]
BaseTools: Update the FV region name as upper letter

Since in the GenFds phase, the FV is generated as upper letter. This
patch update the FV region name as upper letter, it can fix the build
report generate failure on case sensitive file system.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Andrew Fish <afish@apple.com>
3 years agoArmVirtPkg/PlatformBootManagerLib: remove stale FvFile boot options
Laszlo Ersek [Wed, 13 Jul 2016 15:40:15 +0000 (17:40 +0200)]
ArmVirtPkg/PlatformBootManagerLib: remove stale FvFile boot options

(This patch ports OvmfPkg commit 2eb358986052 to ArmVirtPkg. That
functionality was not added to QemuBootOrderLib, because it was (and is)
independent from QEMU and fw_cfg.)

Remove any boot options that point to binaries built into the firmware and
have become stale due to any of the following:
- FvMain's base address or size changed (historical -- see commit
  e191a3114f4c),
- FvMain's FvNameGuid changed,
- the FILE_GUID of the pointed-to binary changed,
- the referenced binary is no longer built into the firmware.

For example, multiple such "EFI Internal Shell" boot options can coexist.
They technically differ from each other, but may not describe any built-in
shell binary exactly. Such options can accumulate in a varstore over time,
and while they remain generally bootable (thanks to the efforts of
BmGetFileBufferByFvFilePath()), they look bad.

Filter out any stale options.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fixes: https://github.com/tianocore/edk2/issues/107
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoOvmfPkg/PlatformPei: add missing auto variable initialization
Ard Biesheuvel [Wed, 13 Jul 2016 14:50:35 +0000 (16:50 +0200)]
OvmfPkg/PlatformPei: add missing auto variable initialization

The E820EntriesCount variable in XenPublishRamRegions() may be
referenced without being initialized on RELEASE builds, since the
ASSERT that fires if the call to XenGetE820Map() fails is compiled
out in that case. So initialize it to 0.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmPkg/ArmGicLib: manage GICv3 SPI state at the distributor
Ard Biesheuvel [Thu, 7 Jul 2016 17:18:39 +0000 (19:18 +0200)]
ArmPkg/ArmGicLib: manage GICv3 SPI state at the distributor

Unlike SGIs and PPIs, which are private to the CPU and are managed at
the redistributor level (which is also a per-CPU construct), shared
interrupts (SPIs) are shared between all CPUs, and therefore managed at
the distributor level (just as on GICv2).

Reported-by: Narinder Dhillon <ndhillonv2@gmail.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoArmPkg/ArmMmuLib: avoid type promotion in TCR_EL1 assignment
Ard Biesheuvel [Wed, 13 Jul 2016 07:06:49 +0000 (09:06 +0200)]
ArmPkg/ArmMmuLib: avoid type promotion in TCR_EL1 assignment

Commit fafb7e9c110e ("ArmPkg: correct TTBR1_EL1 settings in TCR_EL1")
introduced a symbolic constant TCR_TG1_4KB which resolves to (2 << 30),
and ORs it into the value to be written into TCR_EL1 (if executing at
EL1). Since the constant is implicitly typed as signed int, and has the
sign bit set, the promotion that occurs when casting to UINT64 results
in a TCR value that has bits [63:32] all set, which includes mostly
RES0 bits but also the TBIn, AS and IPS fields.

So explicitly redefine all TCR related constants as 'unsigned long'
types, using the UL suffix. To avoid confusion in the future, the
inappropriately named VTCR_EL23_xxx constants have the leading V
removed, and the actual VTCR_EL2 related constants are dropped, given
that we never configure stage 2 translation in UEFI.

Reported-by: Vishal Oliyil Kunnil <vishalo@qti.qualcomm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
3 years agoUefiCpuPkg/CpuMpPei: Remove unnecessary variable
Jeff Fan [Fri, 1 Jul 2016 06:27:26 +0000 (14:27 +0800)]
UefiCpuPkg/CpuMpPei: Remove unnecessary variable

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoUefiCpuPkg/CpuMpPei: Dump message if microcode signature not matched
Jeff Fan [Fri, 1 Jul 2016 06:52:12 +0000 (14:52 +0800)]
UefiCpuPkg/CpuMpPei: Dump message if microcode signature not matched

Verification microcode signature is one enhancement and not one requirement from
IA32 SDM. This update is just to dump debug message instead of ASSERT() if the
updated microcode signature does not match the loaded microcode signature.

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoUefiCpuPkg/CpuMpPei: Skip microcode check/load if it has been loaded
Jeff Fan [Fri, 1 Jul 2016 06:51:10 +0000 (14:51 +0800)]
UefiCpuPkg/CpuMpPei: Skip microcode check/load if it has been loaded

Actually, there is only one microcode region in platform. If microcode has been
loaded, its signature will not be zero and should be loaded successfully.
We needn't to check microcode region and load microcode again. This update is to
skip checking/loading microcode if current microcode signature is not zero.

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3 years agoOvmfPkg: add PciHotPlugInitDxe
Laszlo Ersek [Thu, 30 Jun 2016 18:16:06 +0000 (20:16 +0200)]
OvmfPkg: add PciHotPlugInitDxe

After IncompatiblePciDeviceSupportDxe, this is another small driver /
protocol implementation that tweaks the behavior of the PCI bus driver in
edk2.

The protocol is specified in the Platform Init Spec v1.4a, Volume 5,
Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This
implementation steers the PCI bus driver to reserve the following
resources ("padding") for each PCI bus, in addition to the BARs of the
devices on that PCI bus:
- 2MB of 64-bit non-prefetchable MMIO aperture,
- 512B of IO port space.

The goal is to reserve room for devices hot-plugged at runtime even if the
bridge receiving the device is empty at boot time.

The 2MB MMIO size is inspired by SeaBIOS. The 512B IO port size is
actually only 1/8th of the PCI spec mandated reservation, but the
specified size of 4096 has proved wasteful (given the limited size of our
IO port space -- see commit bba734ab4c7c). Especially on Q35, where every
PCIe root port and downstream port qualifies as a separate bridge (capable
of accepting a single device).

Test results for this patch:
- regardless of our request for 64-bit MMIO reservation, it is downgraded
  to 32-bit,
- although we request 512B alignment for the IO port space reservation,
  the next upstream bridge rounds it up to 4096B.

Cc: "Johnson, Brian J." <bjohnson@sgi.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Suggested-by: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
3 years agoMdeModulePkg/PciBusDxe: recognize hotplug-capable PCIe ports
Laszlo Ersek [Thu, 30 Jun 2016 23:12:29 +0000 (01:12 +0200)]
MdeModulePkg/PciBusDxe: recognize hotplug-capable PCIe ports

Section 7.8.2 of the PCI Express specification (r4.0 v0.3), entitled "PCI
Express Capabilities Register (Offset 02h)", and section 7.8.9 "Slot
Capabilities Register (Offset 14h)" of the same, describe the conditions
when a PCIe port should be considered "supporting hotplug":

- it should be a root complex port or a switch downstream port, and

- it should have the "Slot Implemented" bit set in the Express
  Capabilities Register, and

- it should have the "Hot-Plug Capable" bit set in the Slot Capabilities
  Register.

The first two sub-conditions are already implemented in at least two open
source projects I could find:

- in SeaBIOS by Marcel Apfelbaum: "hw/pci: reserve IO and mem for pci
  express downstream ports with no devices attached"
  <https://code.coreboot.org/p/seabios/source/commit/3aa31d7d6375>,

- in edk2 itself, in the implementation of the "PCI" UEFI Shell command:
  see the "PcieExplainTypeSlot" case label in function
  PciExplainPciExpress(), file
  "ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c".

PciBusDxe recognizes such PCIe ports as bridges, but it doesn't realize
they support hotplug. In turn PciBusDxe omits getting any resource padding
information from the platform's EFI_PCI_HOT_PLUG_INIT_PROTOCOL for these
bridges:

  GatherPpbInfo()                [PciEnumeratorSupport.c]
    GetResourcePaddingPpb()      [PciResourceSupport.c]
      GetResourcePaddingForHpb() [PciHotPlugSupport.c]
        IsPciHotPlugBus()        [PciHotPlugSupport.c]
          //
          // returns FALSE
          //
        //
        // the following is not reached:
        //
        gPciHotPlugInit->GetResourcePadding()

Implement a function called SupportsPcieHotplug() for identifying such
ports, and call it from IsPciHotPlugBus() (after the call to IsSHPC()).

Cc: "Johnson, Brian J." <bjohnson@sgi.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
3 years agoMdeModulePkg/PciBusDxe: look for the right capability in IsSHPC()
Laszlo Ersek [Thu, 30 Jun 2016 23:44:38 +0000 (01:44 +0200)]
MdeModulePkg/PciBusDxe: look for the right capability in IsSHPC()

The PCI Hot Plug capability register block is marked with capability ID
0x0C (EFI_PCI_CAPABILITY_ID_SHPC), not 0x06
(EFI_PCI_CAPABILITY_ID_HOTPLUG).

This bug prevents PciBusDxe from recognizing whether a PCI-to-PCI bridge
supports hotplug. In turn the platform's EFI_PCI_HOT_PLUG_INIT_PROTOCOL is
not consulted for resource padding information:

  GatherPpbInfo()                [PciEnumeratorSupport.c]
    GetResourcePaddingPpb()      [PciResourceSupport.c]
      GetResourcePaddingForHpb() [PciHotPlugSupport.c]
        IsPciHotPlugBus()        [PciHotPlugSupport.c]
          IsSHPC()               [PciHotPlugSupport.c]
            //
            // returns FALSE
            //
        //
        // the following is not reached:
        //
        gPciHotPlugInit->GetResourcePadding()

Look for the correct capability ID.

Cc: "Johnson, Brian J." <bjohnson@sgi.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
3 years agoMdePkg/IndustryStandard: introduce EFI_PCI_CAPABILITY_ID_SHPC
Laszlo Ersek [Thu, 30 Jun 2016 23:35:19 +0000 (01:35 +0200)]
MdePkg/IndustryStandard: introduce EFI_PCI_CAPABILITY_ID_SHPC

The "Pci22.h" header file defines the macro EFI_PCI_CAPABILITY_ID_HOTPLUG
with value 0x06. According to all of:
- later parts of the same header file,
- Appendix H ("Capability IDs") of the PCI Local Bus Specification
  Revision 2.3,
- and Chapter 2 ("Capability IDs") of the PCI Code and ID Assignment
  Specification Revision 0.9,

0x06 means "CompactPCI Hot Swap". It does not mean "PCI Hot-Plug": that
capability is described by ID 0x0C:

  0Ch  PCI Hot-Plug -- This Capability ID indicates that the associated
       device conforms to the Standard Hot-Plug Controller model.

Therefore EFI_PCI_CAPABILITY_ID_HOTPLUG is arguably a misnomer. PciBusDxe
(mis-)uses EFI_PCI_CAPABILITY_ID_HOTPLUG in the IsSHPC() helper function
to identify PCI Hot-Plug capability.

In order to preserve compatibility with existent code, leave
EFI_PCI_CAPABILITY_ID_HOTPLUG alone, and introduce
EFI_PCI_CAPABILITY_ID_SHPC with the right ID value.

Cc: "Johnson, Brian J." <bjohnson@sgi.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
3 years agoOvmfPkg/PlatformBootManagerLib: remove stale FvFile boot options
Laszlo Ersek [Fri, 8 Jul 2016 00:49:45 +0000 (02:49 +0200)]
OvmfPkg/PlatformBootManagerLib: remove stale FvFile boot options

Removes any boot options that point to binaries built into the firmware
and have become stale due to any of the following:
- DXEFV's base address or size changed (historical),
- DXEFV's FvNameGuid changed,
- the FILE_GUID of the pointed-to binary changed,
- the referenced binary is no longer built into the firmware.

For example, multiple such "EFI Internal Shell" boot options can coexist.
They technically differ from each other, but may not describe any built-in
shell binary exactly. Such options can accumulate in a varstore over time,
and while they remain generally bootable (thanks to the efforts of
BmGetFileBufferByFvFilePath()), they look bad.

Filter out any stale options.

This functionality is not added to QemuBootOrderLib, because it is
independent from QEMU and fw_cfg.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg: add a Name GUID to each Firmware Volume
Laszlo Ersek [Tue, 12 Jul 2016 14:48:47 +0000 (16:48 +0200)]
OvmfPkg: add a Name GUID to each Firmware Volume

The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but
the detailed description can be found in Volume 3 of the Platform Init
spec (which is at 1.4a currently).

Adding an FvNameGuid statement to [FV.xxx] has the following effects
(implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"):

- The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero
  value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not
  directly, see below).

- An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to
  address. This object is not followed by any
  EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only
  specifies the Name GUID for the firmware volume.

  The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found
  in the Build directory as a separate file (20 bytes in size):

  Build/Ovmf*/*_GCC*/FV/*.ext

- The new data consume 48 bytes in the following volumes: SECFV,
  FVMAIN_COMPACT, DXEFV. They comprise:

  - 16 padding bytes,

  - EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize
    fields, and Type=EFI_FV_FILETYPE_FFS_PAD),

  - EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above),

  - 4 padding bytes.

  (The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are
  the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point
  immediately past EFI_FIRMWARE_VOLUME_HEADER.)

  The sizes of the firmware volumes don't change, only their internal
  usages grow by 48 bytes. I verified that the statements and calculations
  in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid.

- The new data consume 0 bytes in PEIFV. This is because PEIFV has enough
  internal padding at the moment to accomodate the above structures
  without a growth in usage.

In the future, firmware volumes can be identified by Name GUID (Fv(...)
device path nodes), rather than memory location (MemoryMapped(...) device
path nodes). This is supposed to improve stability for persistent device
paths that refer to FFS files; for example, UEFI boot options.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Suggested-by: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoBaseTools/GenFds: unbreak Region.PadBuffer
Laszlo Ersek [Tue, 12 Jul 2016 13:52:38 +0000 (15:52 +0200)]
BaseTools/GenFds: unbreak Region.PadBuffer

In its current form, Region.PadBuffer() fills every second byte with 0x20,
the default separator string of Python's string.join():

https://docs.python.org/2/library/string.html#string.join

This corrupts some firmware because (a) 0x20 never corresponds to any
ErasePolarity, (b) the PadData produced are actually longer than Size.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fixes: bd907fb6386560e621112beca7b7d381d0003967
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoArmVirtPkg: add name GUIDs to FvMain instances
Ard Biesheuvel [Tue, 12 Jul 2016 09:08:52 +0000 (11:08 +0200)]
ArmVirtPkg: add name GUIDs to FvMain instances

Assign name GUIDs to the FVs that may appear in DevicePath references to
things like the UiApp and the UEFI Shell. This prevents these device
paths from changing inadvertently when the FV ends up in a different
memory location due to external occurrences such as, e.g., a change in
the amount of system memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmVirtPkg: factor out Rules FDF section
Ard Biesheuvel [Tue, 12 Jul 2016 09:01:24 +0000 (11:01 +0200)]
ArmVirtPkg: factor out Rules FDF section

All three current ArmVirtPkg have identical [Rules] sections in their
FDF definitions, and ideally, they should remain that way. So factor
out the definitions into a separate include file, and replace the
existing definitions with !include directives.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmVirtPkg/ArmVirtQemu: factor out shared FV.FvMain definition
Ard Biesheuvel [Tue, 12 Jul 2016 08:59:57 +0000 (10:59 +0200)]
ArmVirtPkg/ArmVirtQemu: factor out shared FV.FvMain definition

The FDF definition of [FV.FvMain] is identical between ArmVirtQemu and
ArmVirtQemuKernel, and needs to remain that way. So factor it out into
a separate include file, and replace both definitions with an !include
directive.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmVirtPkg: align ArmVirtQemuKernel with ArmVirtQemu
Ard Biesheuvel [Tue, 12 Jul 2016 08:49:55 +0000 (10:49 +0200)]
ArmVirtPkg: align ArmVirtQemuKernel with ArmVirtQemu

The platform ArmVirtQemuKernel is intended as an alternative for
ArmVirtQemu that only deviates in the way it is invoked by QEMU, either
from flash address 0x0 (the default ARM reset vector) or via the Linux
kernel boot protocol. So add VirtioRngDxe and HighMemDxe here as well.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmVirtPkg: ArmVirtQemuKernel: make ACPI support AARCH64 only
Ard Biesheuvel [Tue, 12 Jul 2016 11:08:11 +0000 (13:08 +0200)]
ArmVirtPkg: ArmVirtQemuKernel: make ACPI support AARCH64 only

The reasoning of patch 8e2efec6b206:

  No ARM support for ACPI is planned under any OS we intend to run under
  ArmVirtQemu-ARM, so remove the drivers from the ARM build.

applies equally to ArmVirtQemuKernel, so apply the same change there.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmVirtPkg/HighMemDxe: allow patchable PCD for PcdSystemMemoryBase
Ard Biesheuvel [Tue, 12 Jul 2016 12:54:28 +0000 (14:54 +0200)]
ArmVirtPkg/HighMemDxe: allow patchable PCD for PcdSystemMemoryBase

Redefine the reference to PcdSystemMemoryBase in HighMemDxe.inf as
a plain [Pcd] rather than [FixedPcd] (and fix up the code as
appropriate). This allows us to align ArmVirtQemuKernel with
ArmVirtQemu, given that the former uses a patchable PCD not a fixed
PCD.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoMdeModulePkg AtaBusDxe: Fix ATA commands cannot be sent to some devices
Hao Wu [Mon, 11 Jul 2016 04:56:48 +0000 (12:56 +0800)]
MdeModulePkg AtaBusDxe: Fix ATA commands cannot be sent to some devices

If there is no port multiplier (PortMultiplierPort = 0xFFFF), current code
in functions TransferAtaDevice() and TrustTransferAtaDevice() will always
set the DEV bit of the ATA device register. It causes that ATA commands
cannot be sent to some ATA hard drives.

Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
3 years agoBaseTools/GenFds: speed up Region.PadBuffer()
Laszlo Ersek [Mon, 11 Jul 2016 14:26:31 +0000 (16:26 +0200)]
BaseTools/GenFds: speed up Region.PadBuffer()

The current implementation calls both pack() and Buffer.write() Size
times. The new implementation calls both of these methods only once; the
full data to write are constructed locally [1]. The range() function is
replaced by xrange() because the latter is supposed to be faster / lighter
weight [2].

On my laptop, I tested the change as follows: I pre-built the series at
[3] with

  build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -t GCC48 -b DEBUG \
      -D HTTP_BOOT_ENABLE -D SECURE_BOOT_ENABLE

(The series at [3] is relevant because it increases the size of one of the
padded regions by 8.5 MB, slowing down the build quite a bit.)

With all source code already compiled, repeating the above command takes
approximately 45 seconds. With the patch applied, it goes down to 29
seconds.

[1] http://stackoverflow.com/questions/27384093/fastest-way-to-write-huge-data-in-file
[2] https://docs.python.org/2/library/functions.html?highlight=xrange#xrange
[3] http://thread.gmane.org/gmane.comp.bios.edk2.devel/14214

We can also measure the impact with a synthetic test:

> import timeit
>
> test_old = """
> import struct, string, StringIO
> Size = (8 * 1024 + 512) * 1024
> Buffer = StringIO.StringIO()
> PadData = 0xFF
> for i in range(0, Size):
>     Buffer.write(struct.pack('B', PadData))
> """
>
> test_new = """
> import struct, string, StringIO
> Size = (8 * 1024 + 512) * 1024
> Buffer = StringIO.StringIO()
> PadByte = struct.pack('B', 0xFF)
> PadData = string.join(PadByte for i in xrange(0, Size))
> Buffer.write(PadData)
> """
>
> print(timeit.repeat(stmt=test_old, number=1, repeat=3))
> print(timeit.repeat(stmt=test_new, number=1, repeat=3))

The output is

[8.231637001037598, 8.81188416481018, 8.948754072189331]
[0.5503702163696289, 0.5461571216583252, 0.578315019607544]

Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools/GenFds: factor out Region.PadBuffer() method
Laszlo Ersek [Mon, 11 Jul 2016 14:17:23 +0000 (16:17 +0200)]
BaseTools/GenFds: factor out Region.PadBuffer() method

The same logic is used in five places; factor it out to a common method.

Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>