This patch replace some types in GrantTable and the argument Index of
XenHypercallHvmGetParam to what the types should be.
This avoid to have type cast in code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16391 6f19259b-4bc3-4df7-8a09-765794883524
Since a message to XenStore have a lenght of type UINT32, have
XenStore.c deal only with UINT32 instead of a mixmatch with UINTN.
This patch replaces the type of Len in WRITE_REQUEST and the type of the
argument Len of XenStoreWriteStore and XenStoreReadStore.
This patch should avoid to have type cast were it does not make sense to
have them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16390 6f19259b-4bc3-4df7-8a09-765794883524
SVN r16380 ("UEFI 2.4 X509 Certificate Hash and RFC3161 Timestamp
Verification support for Secure Boot") broke the "dbt" variable's
association with its expected namespace GUID.
According to "MdePkg/Include/Guid/ImageAuthentication.h", *all* of the
"db", "dbx", and "dbt" (== EFI_IMAGE_SECURITY_DATABASE2) variables have
their special meanings in the EFI_IMAGE_SECURITY_DATABASE_GUID namespace.
However, the above commit introduced the following expression in
VariableServiceSetVariable():
> - } else if (CompareGuid (VendorGuid, &gEfiImageSecurityDatabaseGuid) &&
> - ((StrCmp (VariableName, EFI_IMAGE_SECURITY_DATABASE) == 0) || (StrCmp (VariableName, EFI_IMAGE_SECURITY_DATABASE1) == 0))) {
> + } else if (CompareGuid (VendorGuid, &gEfiImageSecurityDatabaseGuid) &&
> + ((StrCmp (VariableName, EFI_IMAGE_SECURITY_DATABASE) == 0) || (StrCmp (VariableName, EFI_IMAGE_SECURITY_DATABASE1) == 0))
> + || (StrCmp (VariableName, EFI_IMAGE_SECURITY_DATABASE2)) == 0) {
Simply replacing the individual expressions with the predicates
"GuidMatch", "DbMatch", "DbxMatch", and "DbtMatch", the above
transformation becomes:
> - } else if (GuidMatch &&
> - ((DbMatch) || (DbxMatch))) {
> + } else if (GuidMatch &&
> + ((DbMatch) || (DbxMatch))
> + || DbtMatch) {
In shorter form, we change
GuidMatch && (DbMatch || DbxMatch)
into
GuidMatch && (DbMatch || DbxMatch) || DbtMatch
which is incorrect, because this way "dbt" will match outside of the
intended namespace / GUID.
The error was caught by gcc:
> SecurityPkg/VariableAuthenticated/RuntimeDxe/Variable.c: In function
> 'VariableServiceSetVariable':
>
> SecurityPkg/VariableAuthenticated/RuntimeDxe/Variable.c:3188:71: error:
> suggest parentheses around '&&' within '||' [-Werror=parentheses]
>
> } else if (CompareGuid (VendorGuid, &gEfiImageSecurityDatabaseGuid) &&
> ^
> cc1: all warnings being treated as errors
Fix the parentheses.
This change may have security implications.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Qin Long <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16389 6f19259b-4bc3-4df7-8a09-765794883524
Code added in SVN r16339 ("CryptoPkg Updates to support RFC3161 timestamp
signature verification.") introduced many new uses of the offsetof()
macro. Since the offsetof() macro in "OpenSslSupport.h" casts a pointer to
an "int", it triggers a large number of
error: cast from pointer to integer of different size
[-Werror=pointer-to-int-cast]
errors when building CryptoPkg with gcc-4.8 for X64.
Remedy this by directing offsetof() to the OFFSET_OF() macro in
"MdePkg/Include/Base.h" (which matches how "OpenSslSupport.h" resolves the
va_*() macros too).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Qin Long <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16388 6f19259b-4bc3-4df7-8a09-765794883524
SVN r16339 ("CryptoPkg Updates to support RFC3161 timestamp signature
verification.") introduced the following build failure:
> CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c: In function
> 'TimestampTokenVerify':
> CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c:538:3: error: passing
> argument 2 of 'd2i_TS_TST_INFO' from incompatible pointer type [-Werror]
> TstInfo = d2i_TS_TST_INFO (NULL, &TstTemp, (int)TstSize);
> ^
> In file included from CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c:22:0:
> CryptoPkg/Include/openssl/asn1t.h:803:10: note: expected 'const unsigned
> char **' but argument is of type 'UINT8 **'
> stname *d2i_##fname(stname **a, const unsigned char **in, long len) \
> ^
> CryptoPkg/Include/openssl/asn1t.h:799:2: note: in expansion of macro
> 'IMPLEMENT_ASN1_ENCODE_FUNCTIONS_fname'
> IMPLEMENT_ASN1_ENCODE_FUNCTIONS_fname(stname, itname, fname) \
> ^
> CryptoPkg/Include/openssl/asn1t.h:778:42: note: in expansion of macro
> 'IMPLEMENT_ASN1_FUNCTIONS_fname'
> #define IMPLEMENT_ASN1_FUNCTIONS(stname)
> IMPLEMENT_ASN1_FUNCTIONS_fname(stname, stname, stname)
> ^
> CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c:136:1: note: in expansion of
> macro 'IMPLEMENT_ASN1_FUNCTIONS'
> IMPLEMENT_ASN1_FUNCTIONS (TS_TST_INFO)
> ^
> cc1: all warnings being treated as errors
Note that the cast
(const unsigned char **) &TstTemp
does not match the general edk2 coding style, but it *does* match
other similar casts in this file.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Qin Long <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16387 6f19259b-4bc3-4df7-8a09-765794883524
"Lun" has type UINT64 in this function. The result of the expression
(UINT8) ((Lun >> 8) | 0x40)
depends only on bits [15:8] of "Lun", therefore we can cast "Lun" to
UINT32 before shifting it.
This eliminates an intrinsic when building with VS2010 for Ia32 / NOOPT.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <scott@notabs.org>
[lersek@redhat.com: added commit message]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16386 6f19259b-4bc3-4df7-8a09-765794883524
The SegmentC local variable has type EFI_PHYSICAL_ADDRESS for (justified)
style reasons. However, the 64-bit bit-shifts that it undergoes result in
intrinsic calls when built with VS2010 for Ia32 / NOOPT.
The concrete value of SegmentC, 0xC0000, and the results of the bitops
that are based on it, are statically computeable. Cast SegmentC to UINT32
before subjecting it to bitwise operations; we can see in advance that
this won't lead to range loss.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <scott@notabs.org>
[lersek@redhat.com: dropped now superfluous outermost parens; commit msg]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16385 6f19259b-4bc3-4df7-8a09-765794883524
The current types of subexpressions used in QemuFlashPtr() are as follows.
(We also show the types of "larger" subexpressions, according to operator
binding.)
mFlashBase + (Lba * mFdBlockSize) + Offset
^ ^ ^ ^
| | | |
(UINT8*) EFI_LBA UINTN UINTN
(UINT64)
--------------------------------- ------
(UINT8*) UINTN
------------------------------------------
(UINT8*)
When building with VS2010 for Ia32 / NOOPT, the 64-by-32 bit
multiplication is translated to an intrinsic, which is not allowed in
edk2.
Recognize that "Lba" is always bounded by "mFdBlockCount" (an UINTN) here
-- all callers of QemuFlashPtr() ensure that. In addition, the flash chip
in question is always under 4GB, which is why we can address it at all on
Ia32. Narrow "Lba" to UINTN, without any loss of range.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <scott@notabs.org>
[commit message by lersek@redhat.com]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16384 6f19259b-4bc3-4df7-8a09-765794883524
In the InitializeVariableFvHeader() function, all three of "Offset",
"Start" and "BlockSize" have type UINTN. Therefore the (Offset /
BlockSize) and (Start / BlockSize) divisions can be compiled on all
platforms without intrinsics.
In the current expressions
(EFI_LBA) Offset / BlockSize
(EFI_LBA) Start / BlockSize
"Offset" and "Start" are cast to UINT64 (== EFI_LBA), which leads to
64-by-32 bit divisions on Ia32, breaking the VS2010 / NOOPT / Ia32 build.
The simplest way to fix them is to realize we don't need casts at all.
(The prototypes of QemuFlashEraseBlock() and QemuFlashWrite() are visible
via "QemuFlash.h", and they will easily take our UINTN quotients as
UINT64.)
Suggested-by: Scott Duplichan <scott@notabs.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16383 6f19259b-4bc3-4df7-8a09-765794883524
The MarkMemoryRangeForRuntimeAccess() function passes the Length parameter
(of type UINT64) to the macro EFI_SIZE_TO_PAGES(). When building for the
Ia32 platform, this violates the interface contract of the macro:
[...] Passing in a parameter that is larger than UINTN may produce
unexpected results.
In addition, it trips up compilation by VS2010 for the Ia32 platform and
the NOOPT target -- it generates calls to intrinsics, which are not
allowed in edk2.
Fix both issues with the following steps:
(1) Demote the Length parameter of MarkMemoryRangeForRuntimeAccess() to
UINTN. Even a UINT32 value is plenty for representing the size of the
flash chip holding the variable store. Length parameter is used in the
following contexts:
- passed to gDS->RemoveMemorySpace() -- takes an UINT64
- passed to gDS->AddMemorySpace() -- ditto
- passed to EFI_SIZE_TO_PAGES() -- requires an UINTN. This also guarantees
that the return type of EFI_SIZE_TO_PAGES() will be UINTN, hence we can
drop the outer cast.
(2) The only caller of MarkMemoryRangeForRuntimeAccess() is
FvbInitialize(). The latter function populates the local Length variable
(passed to MarkMemoryRangeForRuntimeAccess()) from
PcdGet32(PcdOvmfFirmwareFdSize). Therefore we can simply demote the local
variable to UINTN in this function as well.
- There's only one other use of Length in FvbInitialize(): it is passed to
GetFvbInfo(). GetFvbInfo() takes an UINT64, so passing an UINTN is fine.
Suggested-by: Scott Duplichan <scott@notabs.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16382 6f19259b-4bc3-4df7-8a09-765794883524
Fix compiler warning about variable set but unused by returning status
of last operation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Garrett Kirkendall <garrett.kirkendall@amd.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16381 6f19259b-4bc3-4df7-8a09-765794883524
Main ChangeLogs includes:
1. Introduce the new GUID and structure definitions for certificate hash and timestamp support;
2. Update Image Verification Library to support DBT signature checking;
3. Update the related SecureBoot Configuration Pages;
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16380 6f19259b-4bc3-4df7-8a09-765794883524
Merge PciInitialization() and AcpiInitialization() into a single
function, PciAcpiInitialization(), and use a PCD set during PEI to
detect the underlying platform type (PIIX4 or Q35/MCH) and therefore
the addresses of the registers to be initialized.
Add LNK[A-H] routing target initialization for the Q35 platform.
Additionally, initialize PCI_INTERRUPT_LINE registers for the typical
set of PCI devices included by QEMU with the Q35 machine type. The
corresponding PIIX4 initialization of PCI_INTERRUPT_LINE registers is
cleaned up and the list of PIIX4 PCI devices updated to the list
typically included with QEMU.
NOTE: The list of PCI devices for which we initialize PCI_INTERRUPT_LINE
is hard-coded, and, depending on how QEMU devices are configured on
the command line, may miss some devices, or (harmlessly) attempt to
initialize devices which are not present in the system. A subsequent
patch will replace this hard-coded list with a mechanism to correctly
initialize PCI_INTERRUPT_LINE for applicable present PCI devices only.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16379 6f19259b-4bc3-4df7-8a09-765794883524
Link DXE_SMM_DRIVER, UEFI_DRIVER, UEFI_APPLICATION, and SMM_CORE against
a valid, non-asserting version of PcdLib, then switch them over to using
the "Dxe" instance of AcpiTimerLib (instead of the "Base" version).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16378 6f19259b-4bc3-4df7-8a09-765794883524
Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may
utilize global variables, use the "Base" AcpiTimerLib instance
(instead of BaseRom) to take advantage of the improved efficiency
of storing the timer register IO address in a global variable.
This leaves only SEC using the BaseRomAcpiTimerLib instance.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16377 6f19259b-4bc3-4df7-8a09-765794883524
Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h
Next, AcpiTimerLib is split out into three instances, for use during
various stages:
- BaseRom: used during SEC, PEI_CORE, and PEIM;
- Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER;
- Base: used by default during all other stages.
Most of the code remains in AcpiTimerLib.c, to be shared by all
instances. The two platform-dependent methods (constructor and
InternalAcpiGetTimerTick) are provided separately by source files
specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c.
Since pre-DXE stages can't rely on storing data in global variables,
methods specific to the "BaseRom" instance will call platform
detection macros each time they're invoked.
The "Base" instance calls platform detection macros only from its
constructor, and caches the address required by InternalAcpiTimerTick
in a global variable.
The "Dxe" instance is very similar to "Base", except no platform
detection macros are called at all; instead, the platform type is
read via a dynamic PCD set from PlatformPei.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
Use a PCD set from PEI to determine the legacy interrupt device
number appropriate for the underlying platform type during protocol
initialization.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16375 6f19259b-4bc3-4df7-8a09-765794883524
Set from PEI, this PCD allows subsequent stages (specifically
DXE_DRIVER and DXE_RUNTIME_DRIVER) to infer the underlying platform
type (e.g. PIIX4 or Q35/MCH) without the need to further query the
Host Bridge for its Device ID.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16374 6f19259b-4bc3-4df7-8a09-765794883524
Set up ACPI power management using registers determined based on
the underlying (PIIX4 or Q35/MCH) platform type.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16373 6f19259b-4bc3-4df7-8a09-765794883524
Introduce macros to detect the underlying platform and access its
ACPI power management registers, based on querying the host bridge
device ID.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16372 6f19259b-4bc3-4df7-8a09-765794883524
This sequence should happen:
* CpuMp.c: Allocate a stack for the APs
* ApStartup.c: Send Start IPI to wake APs in 16-bit real mode
* MpAsm.S: AP enters CpuDxe driver code without stack
- AP grabs a lock
- AP sets up stack
- AP calls CpuMp.c:ApEntryPointInC
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16370 6f19259b-4bc3-4df7-8a09-765794883524
If timeout expires before AP returns from Procedure, the AP should
be terminated, we introduce ResetApStackLess() to send init IPI
to let AP exit Procedurce and re-available.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16366 6f19259b-4bc3-4df7-8a09-765794883524
Due to the implementation of AcquireSpinLock() is not MP safe,
so we should use AcquireSpinLockOrFail directly instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16357 6f19259b-4bc3-4df7-8a09-765794883524
All APs use the same common stack to initialization. after
initialization, APs should switch to the stack of its own.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16351 6f19259b-4bc3-4df7-8a09-765794883524
introduce PCD value: PcdCpuMaxLogicalProcessorNumber and PcdCpuApStackSize,
used for initialize APs stacks.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16350 6f19259b-4bc3-4df7-8a09-765794883524
This routine starts the APs and directs them to run the specified
code.
The specified code is entered without a stack being available.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16349 6f19259b-4bc3-4df7-8a09-765794883524
We'll want to use the structures for AP startup.
Note: It seems previously we were not using '#pragma pack ()' in
CpuGdt.c.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16348 6f19259b-4bc3-4df7-8a09-765794883524
The AP startup code simply jumps into this code with the CpuDxe driver
without setting up a stack for the processor.
Therefore, this code must setup the stack before calling into C code.
This is the basic flow:
* AP enters CpuDxe driver code (AsmApEntryPoint) without stack
- AP grabs a lock
- AP sets up stack
- AP calls CpuMp.c:ApEntryPointInC
- If ApEntryPointInC returns, the lock is freed, and another AP may
run
- The AP C code may call AsmApDoneWithCommonStack to indicate that
the AP is no longer using the stack, and another may therefore
proceed to use the stack and then call ApEntryPointInC
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16347 6f19259b-4bc3-4df7-8a09-765794883524
This is the function the AP assembly code will expect to call after
getting a lock and setting up the stack.
Only one AP will enter this routine at a time.
If ApEntryPointInC exits, then the assembly code will loop around to
grab the lock, setup the stack, and call ApEntryPointInC again.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16346 6f19259b-4bc3-4df7-8a09-765794883524
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16345 6f19259b-4bc3-4df7-8a09-765794883524
Even if the CPU id registers indicate hardware support for the
System Register interface to the GIC, higher exception levels
may disable that interface and only allow access through MMIO.
So move the enabling of the SRE bit to the GIC version detection
routine: if we trigger an exception, we would have anyway at a
later stage, so the net effect is the same. However, if setting
the bit doesn't stick, it means we can switch to MMIO and proceed
normally otherwise.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16344 6f19259b-4bc3-4df7-8a09-765794883524
Anthony PERARD
Laszlo Ersek
Scott Duplichan
Garrett Kirkendall
Qin Long
Gabriel Somlo
Chen Fan
Jordan Justen
Ard Biesheuvel
Olivier Martin
Jaben Carsey