Dandan Bi [Tue, 15 Nov 2016 11:13:33 +0000 (19:13 +0800)]
MdeModulePkg/SetupBrowser:Don't support password without interactive flag
In current SetupBrowser, the logic related to non-interative password
is not correct. How to support it correctly or whether support it
is still under investigation. First step remove the incorrect logic.
Cc: Liming Gao <liming.gao@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Haojian Zhuang [Wed, 23 Nov 2016 13:36:21 +0000 (21:36 +0800)]
EmbeddedPkg/MmcDxe: invoke SetIos() protocol method to set speed and width
Add the interface to change the bus width and speed.
By default, MMC is initialized with 1-bit mode and less than 400KHz bus
clock. It causes MMC working inefficiently.
Set I/O bus width on both MMC controller and EXTCSD. Otherwise, it may
cause unmatched failure case. And support more timing mode, high speed,
HS200 & HS400 mode.
Haojian Zhuang [Wed, 23 Nov 2016 13:36:23 +0000 (21:36 +0800)]
ArmPlatformPkg/PL180MciDxe: update for identifying SD
When CMD6 & ACMD51 are added into identifying SD process, PL180
should also support CMD6 & ACMD51. Otherwise, it will hang when
system tries to read expected data.
Marcin Wojtas [Thu, 24 Nov 2016 07:54:33 +0000 (08:54 +0100)]
MdeModulePkg/AtaAtapiPassThru: Ensure GHC.AE bit is always set in Ahci
According to AHCI Spec 1.3 GHC.AE bit description:
"The implementation of this bit is dependent upon the value of the
CAP.SAM bit. If CAP.SAM is '0', then GHC.AE shall be read-write and shall
have a reset value of '0'. If CAP.SAM is '1', then AE shall be read-only
and shall have a reset value of '1'."
Being in AhciMode, for proper operation it is required, that GHC.AE bit
is always set, before any other AHCI registers are written to. Current
AhciMode implementation, both in AhciReset() and AhciModeInitialization()
functions, set GHC.AE bit only depending on 'CAP.SAM == 0' condition,
assuming (according to the AHCI spec), that otherwise it has to be set
anyway. It may however happen, that even if 'CAP.SAM == 1', GHC.AE
requires updating by software.
This patch enables in AhciMode setting GHC.AE in case its initial value
is '0'. It fixes AHCI support for Marvell Armada 70x0 and 80x0 SoC
families. The change is transparent to all other platforms.
OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier
v2:
* Changes suggested by Laszlo:
- change the catch-all (*) to GCC5, from GCC44
- remove the (5.*.*) pattern from GCC49
- generate error for GCC < 4.4
In v3, also generate error for really GCC < 4.4, like GCC 1.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Richard Thomaiyar <richard.marian.thomaiyar@intel.com> Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Feng Tian [Wed, 23 Nov 2016 01:46:32 +0000 (09:46 +0800)]
MdeModulePkg/Xhci: Add 10ms delay before sending SendAddr cmd to dev
We send ADDRESS DEVICE CMD in XhcInitializeDeviceSlot(), which will
cause XHC issue a USB SET_ADDRESS request to the USB Device.
According to USB spec, there should have a 10ms delay before this
operation after resetting a given port.
But in original code, there is a possible path which may have no such
10ms delay:
UsbHubResetPort()->UsbHubSetPortFeature()->Stall(20)->UsbHubGetPortSt
atus()->XhcPollPortStatusChange()->(if RESET_C bit is set)->
XhcInitializeDeviceSlot()->(if RESET_C bit is set)->Stall(10)
Jiewen Yao [Tue, 22 Nov 2016 07:05:11 +0000 (15:05 +0800)]
UefiCpuPkg/PiSmmCpu: Correct exception message.
This patch fixes the first part of
https://bugzilla.tianocore.org/show_bug.cgi?id=242
Previously, when SMM exception happens, "stack overflow" is misreported.
This patch checked the PF address to see it is stack overflow, or
it is caused by SMM page protection.
It dumps exception data, PF address and the module trigger the issue.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jeff Fan <jeff.fan@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Laszlo Ersek [Tue, 22 Nov 2016 12:58:54 +0000 (13:58 +0100)]
UefiCpuPkg/MpInitLib: fix feature test for Extended Topology CPUID leaf
According to the Intel SDM (325462-060US / September 2016),
> INPUT EAX = 0BH: Returns Extended Topology Information
>
> [...] Software must detect the presence of CPUID leaf 0BH by verifying
> (a) the highest leaf index supported by CPUID is >= 0BH, and
> (b) CPUID.0BH:EBX[15:0] reports a non-zero value. [...]
The "GetApicId" sections in the Ia32 and X64 "MpFuncs.nasm" files do not
perform check (b).
This causes an actual bug in the following OVMF setup:
- the QEMU/KVM guest's VCPU model is set to "host", that is, "the CPU
visible to the guest should be exactly the same as the host CPU".
Under "GetApicId", check (a) passes: the CPUID level of the W3550 is
exactly 11 decimal. However, leaf 11 itself is not supported, therefore
EDX is set to zero:
> If a value entered for CPUID.EAX is less than or equal to the maximum
> input value and the leaf is not supported on that processor then 0 is
> returned in all the registers.
Because we don't check (b), the "GetProcessorNumber" section of the code
is reached with an initial APIC ID of 0 in EDX on all of the APs. Given
that "GetProcessorNumber" searches the
"MP_CPU_EXCHANGE_INFO.CpuInfo[*].InitialApicId" fields for a match, all
APs enter ApWakeupFunction() with an identical "NumApsExecuting"
parameter. This results in unpredictable guest behavior (crashes, reboots,
hangs etc).
Reorganize the "GetApicId" section and add the missing check in both
assembly files.
Cc: Jeff Fan <jeff.fan@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>
Laszlo Ersek [Tue, 22 Nov 2016 11:43:17 +0000 (12:43 +0100)]
UefiCpuPkg/LocalApicLib: fix feature test for Extended Topology CPUID leaf
According to the Intel SDM (325462-060US / September 2016),
> INPUT EAX = 0BH: Returns Extended Topology Information
>
> [...] Software must detect the presence of CPUID leaf 0BH by verifying
> (a) the highest leaf index supported by CPUID is >= 0BH, and
> (b) CPUID.0BH:EBX[15:0] reports a non-zero value. [...]
The LocalApicLib instances in UefiCpuPkg do not perform check (b).
This causes an actual bug in the following OVMF setup:
- the QEMU/KVM guest's VCPU model is set to "host", that is, "the CPU
visible to the guest should be exactly the same as the host CPU".
In the GetInitialApicId() function, check (a) passes: the CPUID level of
the W3550 is exactly 11 decimal. However, leaf 11 itself is not supported,
therefore EDX is set to zero:
> If a value entered for CPUID.EAX is less than or equal to the maximum
> input value and the leaf is not supported on that processor then 0 is
> returned in all the registers.
Because we don't check (b), we return 0 as initial APIC ID on the BSP and
on all of the APs as well.
Add the missing check.
Cc: Jeff Fan <jeff.fan@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>
VM related defs are now in EbcVmTest.h, and opocode related definitions in
Ebc.h.
Because it is used by both the EBC Debugger and driver,
EbcDebugSignalException() sees its definition factorized in
EbcDebuggerHook.h.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Pete Batard [Wed, 16 Nov 2016 13:24:08 +0000 (21:24 +0800)]
MdeModulePkg/EbcDxe: prepare support for EBC Debugger
* This patch introduces EbcDebuggerHook.c/h and inserts the required
EBCDebugger references into the existing EBC source files.
* With all the hooks defined to their empty version in EbcDebuggerHook.c
the existing EBC VM behaviour is left unaffected.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Dandan Bi [Tue, 22 Nov 2016 02:39:38 +0000 (10:39 +0800)]
MdeModulePkg/DisplayEngine: Return the selectable menu correctly
When returning selectable menu, should return the menu in current form,
the codes miss to do the check. Now returning the selectable menu behind
the codes "if ((UINTN) Distance + NextMenuOption->Skip > GapToTop)".
Then can cover the check, can return the menu correctly.
Hao Wu [Mon, 21 Nov 2016 07:38:11 +0000 (15:38 +0800)]
SecurityPkg Tcg2Dxe: ASSERT to ensure 'VarData' is not NULL
The logic in functions ReadAndMeasureVariable() and MeasureVariable()
within Tcg2Dxe ensure that 'VarData' will not be NULL before calling
TcgDxeHashLogExtendEvent() at line 1716.
This commit adds ASSERT as warnings for the case that will not happen.
section. Their types, default values, and token values remain unchanged.
Only UefiCpuPkg/PiSmmCpuDxeSmm consumes these PCDs, specifically on the
call stack of its entry point function, and it turns them into static or
dynamically allocated data in SMRAM:
and this path is exercised during S3 resume (as stated by the comment in
SmmInitHandler() too, "Initialize private data during S3 resume").
While we can call the PCD protocol (via PcdLib) for fetching dynamic PCDs
in the entry point function, we cannot do that at S3 resume. Therefore
pre-fetch PcdCpuSmmSyncMode into a new global variable (which lives in
SMRAM) in InitializeMpServiceData(), just before calling
InitializeMpSyncData(). This way InitializeMpSyncData() can retrieve the
stashed PCD value from SMRAM, regardless of the boot mode.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Paolo Bonzini <pbonzini@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=230
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Jeff Fan [Fri, 18 Nov 2016 02:46:43 +0000 (10:46 +0800)]
MdeModulePkg/PiSmmCore: Cache CommunicationBuffer info before using it
gSmmCorePrivate->CommunicationBuffer and gSmmCorePrivate->BufferSize locate at
runtime memory region. That means they could be modified by non-SMM code during
runtime.
We should cache them into SMM local variables before we verify them. After
verification, we should use the cached ones directly instead of the ones in
gSmmCorePrivate.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Star Zeng [Wed, 16 Nov 2016 09:17:36 +0000 (17:17 +0800)]
SecurityPkg Tcg2Dxe: Get correct digest list size
Current code uses GetDigestListSize(DigestList) to get
digest list size, that is incorrect.
The code should get digest list size of digests copied
into event2 log, those digests are compacted, so
GetDigestListBinSize() should be used.
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: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Star Zeng [Fri, 18 Nov 2016 01:54:21 +0000 (09:54 +0800)]
SecurityPkg TPM2: Update desc for param Buffer of GetDigestListSize()
To make the description more clear, update the description
for parameter Buffer of GetDigestListSize() to
"Buffer to hold copied TPML_DIGEST_VALUES compact binary.".
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: Star Zeng <star.zeng@intel.com>
Reviewed-by : Chao Zhang <chao.b.zhang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
When the input path for API PathRemoveLastItem() is a root path like
'fs0:\', the API will return TRUE (indicating a directory or file was
removed from the path) and modifies the path to 'fs0:'. In fact, there's
no directory or file removed in the above case.
This commit adds additional check to resolve this issue and modifies the
API's description to make it more straightforward.
Current implementation always creates PlatformRecovery0000
pointing to \EFI\BOOT\BOOT$(ARCH).efi but it may overwrite
PlatformRecovery#### created before (maybe by a DXE driver).
The patch only uses the smallest unused option number for
the \EFI\BOOT\BOOT$(ARCH).efi PlatformRecovery#### to avoid
overwriting already-created PlatformRecovery####.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jie Lin <jie.lin@intel.com> Reviewed-by: Sunny Wang <sunnywang@hpe.com>
Ruiyu Ni [Tue, 15 Nov 2016 09:50:43 +0000 (17:50 +0800)]
MdeModulePkg/BdsDxe: Fix bug to run non-first PlatformRecovery####
The implementation doesn't check the LoadOptions[Index].Status but
only depends on the Status returned from
EfiBootManagerProcessLoadOption(), which results only the first
PlatformRecovery#### runs.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jie Lin <jie.lin@intel.com> Reviewed-by: Sunny Wang <sunnywang@hpe.com>
Ruiyu Ni [Mon, 14 Nov 2016 05:25:54 +0000 (13:25 +0800)]
PcAtChipsetPkg/PcRtc: Handle NULL table entry in RSDT/XSDT
The ACPI code may reserve the first entry for a certain table
(might be FACS) to help with OS compatible issues.
We need to skip the NULL table entry in RSDT/XSDT.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Jeff Fan [Tue, 15 Nov 2016 08:29:22 +0000 (16:29 +0800)]
UefiCpuPkg/SecCore: Correct print format for stack information
v2:
Per Laszlo and Andrew's comments at
https://lists.01.org/pipermail/edk2-devel/2016-November/004759.html
SecCoreData->StackBase is VOID * type. We should use %p to dump VOID * type.
SecCoreData->StackSize is UINTN type, but %x only could print unsinged-int
type. We will cast it to UINT32 firstly and then use %x to print it.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Jeff Fan [Wed, 16 Nov 2016 14:25:56 +0000 (22:25 +0800)]
MdeModulePkg/PiSmmCpuDxeSmm: Check RegisterCpuInterruptHandler status
Once platform selects the incorrect instance, the caller could know it from
return status and ASSERT().
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Current CpuExceptionHanderLibNull instance returns EFI_SUCCESS for all three
services. If platform does not want to hook the Exception vector for some
modules (For example DxeCore), it could select this NULL instance in DSC file
for those module. But some modules that want to consume
RegisterCpuInterruptHandler() cannot use NULL instance. If platform does not
select the correct library instance, it will does work. But the caller does not
recognize it.
This update is to return EFI_UNSUPPORTED on RegisterCpuInterruptHandler() in
NULL instance instead of return EFI_SUCCESS. Once platform selects this NULL
instance, the caller could know it from return status.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Michael Kinney [Thu, 17 Nov 2016 20:43:04 +0000 (12:43 -0800)]
UefiCpuPkg/PiSmmCpuDxeSmm: Add volatile to mNumberToFinish
Add volatile qualifier to mNumberToFinish to prevent GCC 5.4
compiler from optimizing away required logic in ACPI S3 resume.
Cc: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Michael Kinney [Thu, 17 Nov 2016 20:41:35 +0000 (12:41 -0800)]
UefiCpuPkg/PiSmmCpuDxeSmm: TransferApToSafeState() use UINTN params
Update TransferApToSafeState() use UINTN params to reduce the
number of type casts required in these calls. Also change
the NumberToFinish parameter from UINT32* to UINTN
NumberToFinishAddress to resolve issues with conversion from
a volatile pointer to a non-volatile pointer. The assembly
code that receives the NumberToFinishAddress value must treat
that memory location as a volatile to track the number of APs.
Cc: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Michael Kinney [Thu, 17 Nov 2016 19:08:38 +0000 (11:08 -0800)]
MdePkg/BaseSynchronizationLib: Fix function names in function headers
Some of the function names in function header comment blocks in
assembly files do not match the symbol name in the assembly sources.
Update function header comment blocks to match symbol name.
Cc: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
The SpinLock functions in the SynchronicationLib use volatile
parameters to keep compiler from optimizing these functions
too much. The volatile keyword is missing from the Interlocked*()
functions in this same library instance. Update the library instance
to consistently use volatile on all functions in the
SynchronizationLib class.
Cc: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Michael Kinney [Thu, 17 Nov 2016 18:57:53 +0000 (10:57 -0800)]
MdePkg/Include: Add volatile to SynchronizationLib parameters
The SpinLock functions in the SynchronicationLib use volatile
parameters to keep compiler from optimizing these functions
too much. The volatile keyword is missing from the Interlocked*()
functions in this same library class. Update the library class
to consistently use volatile on all functions in this class.
Cc: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
The script 'BuildEnv' modifies the value of the environment variable
'PACKAGES_PATH' (line 44). The script will substitute the ':' symbol
(separating multiple paths) with a space.
This is not supposed to happen since users might later use 'PACKAGES_PATH'
during the code-building process under a multiple-workspace scenario.
Maurice Ma [Thu, 17 Nov 2016 03:22:32 +0000 (19:22 -0800)]
CorebootPayloadPkg/CbSupportPei: Fix the memory map issue
When coreboot reports memory range across 1MB, the current code
cannot handle it properly. In this case the range should be
adjusted to start from 1MB instead since the memory resource
below 1MB has been preprocessed by CbSupportPei module.
This patch fixed the coreboot + UEFI payload hang issue when
running on QEMU due to incorrect memory map.
Cc: Prince Agyeman <prince.agyeman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
On old platform without PCIe express support, the PciLib needs to
be mapped to PciLibCf8 instance to make it work. On new platform
with PCIe express support, the PciLib needs to be mapped to
PciLibPciExpress to allow access to extended PCIe configuration
space. This patch allows to select the PciLib instance between
PciLibCf8 and PciLibPciExpress using the PCIE_BASE macro through
build command line.
Cc: Prince Agyeman <prince.agyeman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
Make the smallest change possible to workaround a VS2015
build error. The change is to the loop that handles the
case where neither the source nor the destination are
64-bit or 32-bit aligned and the logic falls through to
a loop that performs the copy as bytes. Only the loop
that copies bytes backwards needs to be updated to avoid
the VS2015 build error.
Laszlo Ersek [Wed, 16 Nov 2016 22:31:11 +0000 (23:31 +0100)]
UefiCpuPkg/MpInitLib: support 64-bit AP stack addresses
The cached "CPU_INFO_IN_HOB.ApTopOfStack" field currently has type UINT32.
This is not ideal because the AP stacks are located within
"CpuMpData->Buffer", which is allocated with a plain AllocatePages() call
in MpInitLibInitialize():
platform CpuMpPei included PEI RAM > 4GB result
-------- ----------------- ------------- ------
Ia32 * n/a good
Ia32X64 no n/a BAD
Ia32X64 yes n/a good
X64 no * BAD
X64 yes no good
X64 yes yes BAD
- If we are on an Ia32X64 or X64 platform that does not include CpuMpPei,
then CpuDxe cannot reuse the CPU_INFO_IN_HOB structures preallocated by
CpuMpPei (through the CpuInitMpLib GUID HOB), and then AllocatePages()
-- invoked first in 64-bit DXE -- could return an address outside of
32-bit address space.
- If we are on an X64 platform where the permanent PEI RAM extends above
the 32-bit address space, then the same issue can surface even if
CpuMpPei is included: even the original allocation of the
CPU_INFO_IN_HOB structures, by CpuMpPei, could be satisfied from above
4GB.
The original "AP init" branch in "X64/MpFuncs.nasm" correctly considers a
64-bit stack start: the "MP_CPU_EXCHANGE_INFO.StackStart" field has type
UINTN, and the code uses QWORD addition and movement to set RSP from it.
Adapt the "GetApicId" branch of "X64/MpFuncs.nasm":
- change the type of "CPU_INFO_IN_HOB.ApTopOfStack" to UINT64,
- remove the explicit truncation to UINT32 in InitializeApData(),
- update the "GetNextProcNumber" iteration size to the new size of
"CPU_INFO_IN_HOB",
- set RSP with a QWORD movement from "CPU_INFO_IN_HOB.ApTopOfStack".
Because the same CPU_INFO_IN_HOB structure is used by "Ia32/MpFuncs.nasm",
we have to update the "GetNextProcNumber" iteration size there as well.
The ESP setting can be preserved as a DWORD movement from the original
offset (decimal 12), since our integers are little endian.
Cc: Jeff Fan <jeff.fan@intel.com> Fixes: 845c5be1fd9bf7edfac4a103dfab70829686978f
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
The recent patch "UefiCpuPkg/MpInitLib: Program AP stack in fixed address"
inadvertently broke the first startup of APs during X64 PEI, because in
the TestLock section of the code, it replaced the access to the
NumApsExecuting counter with an access to the unrelated InitFlag field.
Cc: Jeff Fan <jeff.fan@intel.com> Fixes: 845c5be1fd9bf7edfac4a103dfab70829686978f
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Cc: Jeff Fan <jeff.fan@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>
Laszlo Ersek [Wed, 16 Nov 2016 23:05:32 +0000 (00:05 +0100)]
UefiCpuPkg/DxeMpInitLib: remove duplicate HobLib class dependency
Cc: Jeff Fan <jeff.fan@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>
The new GUID gEdkiiPiSmmMemoryAttributesTableGuid and its associated
structure are based on the EFI_MEMORY_ATTRIBUTES_TABLE and GUID from the
UEFI Specification.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: update commit message as requested by Michael Kinney] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Kelly Steele <kelly.steele@intel.com> Cc: Jeff Fan <jeff.fan@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Jiewen Yao [Sun, 23 Oct 2016 15:19:52 +0000 (23:19 +0800)]
UefiCpuPkg/PiSmmCpuDxeSmm: Add paging protection.
PiSmmCpuDxeSmm consumes SmmAttributesTable and setup page table:
1) Code region is marked as read-only and Data region is non-executable,
if the PE image is 4K aligned.
2) Important data structure is set to RO, such as GDT/IDT.
3) SmmSaveState is set to non-executable,
and SmmEntrypoint is set to read-only.
4) If static page is supported, page table is read-only.
We use page table to protect other components, and itself.
If we use dynamic paging, we can still provide *partial* protection.
And hope page table is not modified by other components.
The XD enabling code is moved to SmiEntry to let NX take effect.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Jiewen Yao [Sun, 23 Oct 2016 15:21:20 +0000 (23:21 +0800)]
UefiCpuPkg/dec: Add PcdCpuSmmStaticPageTable.
If enabled, SMM will not use on-demand paging.
SMM will build static page table for all memory.
The page table size depend on 2 things:
1) The 1G paging capability.
2) The whole system memory/MMIO addressing capability.
A) If the system only supports 2M paging,
When the whole memory/MMIO is 32bit, we only need 1+1+4=6 pages for 4G.
When the whole memory/MMIO is 39bit, we need 1+1+256 pages (~ 1M)
When the whole memory/MMIO is 48bit, we need 1+256+256*256 pages (~ 257M)
B) If the system supports 1G paging.
When the whole memory/MMIO is 32bit, we only need 1+1+4=6 pages for 4G.
(We still generate 2M page for maintenance consideration.)
When the whole memory/MMIO is 39bit, we still need 6 pages.
(We setup 1G paging for >1G.)
When the whole memory/MMIO is 48bit, we need 1+256 pages (~ 1M).
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
The SMM memory attribute table concept is similar to UEFI
memory attribute table.
The new file MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
and the new code in MdeModulePkg/Core/PiSmmCore/Page.c
are based on the algorithms and implementation from
MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
and MdeModulePkg/Core/Dxe/Mem/Page.c.
These new components are based on the Memory Attributes Table
feature from the UEFI Specification and the existing DXE Core
implementation that supports that feature.
This SMM MemoryAttributes table is produced at SmmEndOfDxe event.
So that the consumer (PiSmmCpu) may consult this table
to set memory attribute in page table.
This patch also installs LoadedImage protocol to SMM
protocol database, so that the SMM image info can be
got easily to construct the PiSmmMemoryAttributes table.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Jeff Fan [Mon, 14 Nov 2016 03:38:25 +0000 (11:38 +0800)]
UefiCpuPkg/MpInitLib: Program AP stack in fixed address
Currently, MpInitLib will program AP stack in dynamic address. Each processor
will calculate its stack address by adding stack size based on the last stack
address. That means AP may have the different stack address everytime it is
wakeup by INIT-SIPI-SIPI.
When all APs have wakeup to execute AP task, each each has been assigned one
stack address. Once the timeout happened on some of APs, BSP will send INIT-
SIPI-SIPI to wake up APs. We need to re-assign stack for APs. Based on the
current implementation, we might assign one stack address used by other APs.
It will cause the unexpected stack overlapped issue.
This fix changed the stack assignment policy. We will record the stack address
assigned to AP at first time AP wakeup. When AP failed on AP task, BSP could
reassigned the same stack for it.
Getting initial APIC ID in assembly code could help AP to get saved its stack
address.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael D 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>
Jeff Fan [Mon, 14 Nov 2016 02:30:03 +0000 (10:30 +0800)]
UefiCpuPkg/MpInitLib: Force sending INIT-SIPI-SIPI to reset APs
If BSP found APs timeout happened when AP executing AP task, BSP will reset APs
by WakeUpAP(). However, if ApLoopMode is ApMwaitLoop or ApRunLoop, WakeUpAp()
will try to write semaphore in memory to wake up AP. It cannot wake up APs
actually if APs still executing AP task.
This fix is to set ApInitReconfig flag to force BSP to send INIT-SIPI-SIPI to
wake up APs.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael D 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>