The size of the ClassIdentifier is apparently wrong in the structure. In my
testing it caused the vendor class data to be displayed as bogus
"HTTPClient:Arch00016x:UNDI00300". After correcting the size the vendor class
data is "HTTPClient:Arch00016:UNDI003000" which looks good to me.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Zhang Lubo <lubo.zhang@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Physical Presence state reporting is constrained by physical presence caching in variable driver. For example, reporting must be prior to Physical Presence caching. Physical Presence state becomes constant rather than instant after caching. Therefore, PlatformSecureLib is responsible for reporting Physical Presence state in expected way.
This reverts commit 90fa53213e.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>
The ordinary small code model for x86_64 cannot be used in UEFI, since
it assumes the executable is loaded in the first 2 GB of memory.
Therefore, we use the large model instead, which can execute anywhere,
but uses absolute 64-bit wide quantities for all symbol references,
which is costly in terms of code size.
So switch to the PIE small code model, this uses 32-bit relative
references where possible, but does not make any assumptions about the
load address (i.e., all absolute symbol references are 64-bits wide).
Note that, due to the 'protected' visibility pragma introduced in an
earlier patch, there is no need for the EDK2 build system to deal with
GOT related ELF relocation types.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
When building position independent (PIC) ELF objects, the GCC compiler
assumes that each symbol with external linkage may potentially end up
being exported from a shared library, which means that each of those
symbols may be subject to symbol preemption, i.e., the executable
linking to the shared library at runtime may override symbols exported
by the shared library, and every internal reference held by the shared
library itself *must* be made to point to the overridden version instead.
For this reason, PIC code symbol references always go via the Global
Offset Table (GOT), even if the code in question references symbols that
are defined in the same compilation unit. The GOT refers to each symbol
by absolute address, and so each entry is subject to runtime relocation.
Since not every symbol with external linkage is ultimately exported from
a shared library, the GCC compiler allows control over symbol visibility
using attributes, command line arguments and pragmas, where 'protected'
means that the symbol is only referenced by the shared library itself.
Due to the poor hygiene in EDK2 regarding the use of the 'static'
modifier, many symbols that are local to their compilation unit end up
being referenced indirectly via the GOT when building PIC code.
In UEFI, there are no shared libraries and so there is no need to deal
with symbol preemption, and we can mark every symbol reference protected.
The only method that applies to all symbol definitions as well as
declarations is the #pragma. So set the visibility 'protected' pragma when
building PIC code for X64 using GCC. Note that this affects code generated
with the -fpie compiler switch as well as the -fpic compiler switch.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
This is never set anymore, so unsetting it or testing whether it is unset
no longer makes any sense.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Now that we switched to the __builtin_ms_va_list VA_LIST type for
GCC/X64, we can trust the compiler to do the right thing even under
optimization, and so we can enable -Os optimization all the way back
to GCC44, and drop the -D define that prevents the use of the __builtin
VA_LIST types. Note that this requires the -maccumulate-outgoing-args
switch as well.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Both GCC and LLVM 3.8 64bits support new variable argument (VA)
intrinsics for Microsoft ABI, enable these new VA intrinsics for
GNUC family 64bits code build. These VA intrinsics are only
permitted use in 64bits code, so not use them in 32bits code build.
The original 32bits GNU VA intrinsics has the same calling convention
as MS, so we don't need change them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven.shi@intel.com>
[ardb: update CPP logic so that the change only applies to X64]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Set the #define NO_MSABI_VA_FUNCS that will be introduced in a subsequent
patch to avoid the use of the MS ABI in variadic functions. In EDK2, such
functions normally require the EFIAPI modifier to be used, but for external
libraries such as OpenSSL, which lack these annotations, it is easier to
simply revert to the default SysV style VA_LIST ABI.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
GCC v4.4 does not implement __builtin_unreachable(), so avoid using
it when building with this version or earlier.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The commit 8b9311 changed the zeroing of mSmmMpSyncData of type
SMM_DISPATCHER_MP_SYNC_DATA by the following patch.
- ZeroMem (mSmmMpSyncData, mSmmMpSyncDataSize);
+ mSmmMpSyncData->SwitchBsp = FALSE;
mSmmMpSyncDataSize not only includes SMM_DISPATCHER_MP_SYNC_DATA, but
also includes the SMM_CPU_DATA_BLOCK array and one BOOLEAN variable
array as shown here:
mSmmMpSyncDataSize = sizeof (SMM_DISPATCHER_MP_SYNC_DATA) +
(sizeof (SMM_CPU_DATA_BLOCK) + sizeof (BOOLEAN)) *
gSmmCpuPrivate->SmmCoreEntryContext.NumberOfCpus;
This patch restores the original ZeroMem() to clear all CPU Sync data.
The commit 8b9311 may cause unexpected behavior.
v2:
Mentioned CandidateBsp array in comments to make it more accurate.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@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: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
OpenSSL 1.0.2h was released with several severity fixes at
03-May-2016 (https://www.openssl.org/news/secadv/20160503.txt).
Upgrade the supported OpenSSL version in CryptoPkg/OpensslLib to
catch the latest release 1.0.2h.
Cc: Ting Ye <ting.ye@intel.com>
Cc: David Woodhouse <David.Woodhouse@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
This commit will scan all the EFI raw section instances within the
module's FV to make sure the NVDIMM root device SSDT can be properly
located.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Zhang Chao B <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
BaseLib Ia32 InternalSwitchStack.S has no matched InternalSwitchStack.nasm.
Use ObjDump to verify the output object files be same.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Commits 28ee581646 and 246cd9085f 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>
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>
> 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>
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>
Michael Chang
Zhang, Chao B
Ard Biesheuvel
Shi, Steven
Jeff Fan
Qin Long
Hao Wu
Liming Gao
Ruiyu Ni
Laszlo Ersek
Satya Yarlagadda