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>
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>
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>
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>
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>
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>
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 a81abf1616 ("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>
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>
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>
Jeff Fan
Ruiyu Ni
Laszlo Ersek
Satya Yarlagadda
Fu Siyuan
Yonghong Zhu
Zhang Lubo