2013-11-22 07:24:41 +01:00
|
|
|
/** @file
|
|
|
|
CPU exception handler library implemenation for DXE modules.
|
|
|
|
|
2022-05-18 11:51:21 +02:00
|
|
|
Copyright (c) 2013 - 2022, Intel Corporation. All rights reserved.<BR>
|
2019-04-04 01:07:22 +02:00
|
|
|
SPDX-License-Identifier: BSD-2-Clause-Patent
|
2013-11-22 07:24:41 +01:00
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
#include <PiDxe.h>
|
|
|
|
#include "CpuExceptionCommon.h"
|
|
|
|
#include <Library/DebugLib.h>
|
|
|
|
#include <Library/MemoryAllocationLib.h>
|
2018-01-15 02:45:59 +01:00
|
|
|
#include <Library/UefiBootServicesTableLib.h>
|
2013-11-22 07:24:41 +01:00
|
|
|
|
|
|
|
CONST UINTN mDoFarReturnFlag = 0;
|
|
|
|
|
2022-05-18 08:45:37 +02:00
|
|
|
RESERVED_VECTORS_DATA mReservedVectorsData[CPU_INTERRUPT_NUM];
|
|
|
|
EFI_CPU_INTERRUPT_HANDLER mExternalInterruptHandlerTable[CPU_INTERRUPT_NUM];
|
2022-05-18 07:56:05 +02:00
|
|
|
EXCEPTION_HANDLER_DATA mExceptionHandlerData = {
|
2022-05-18 11:51:21 +02:00
|
|
|
CPU_INTERRUPT_NUM,
|
|
|
|
0, // To be fixed
|
2022-05-18 07:56:05 +02:00
|
|
|
mReservedVectorsData,
|
|
|
|
mExternalInterruptHandlerTable
|
|
|
|
};
|
2013-11-22 07:24:41 +01:00
|
|
|
|
2022-08-26 09:04:47 +02:00
|
|
|
UINT8 mBuffer[CPU_STACK_SWITCH_EXCEPTION_NUMBER * CPU_KNOWN_GOOD_STACK_SIZE
|
|
|
|
+ CPU_TSS_GDT_SIZE];
|
UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
If Stack Guard is enabled and there's really a stack overflow happened during
boot, a Page Fault exception will be triggered. Because the stack is out of
usage, the exception handler, which shares the stack with normal UEFI driver,
cannot be executed and cannot dump the processor information.
Without those information, it's very difficult for the BIOS developers locate
the root cause of stack overflow. And without a workable stack, the developer
cannot event use single step to debug the UEFI driver with JTAG debugger.
In order to make sure the exception handler to execute normally after stack
overflow. We need separate stacks for exception handlers in case of unusable
stack.
IA processor allows to switch to a new stack during handling interrupt and
exception. But X64 and IA32 provides different ways to make it. X64 provides
interrupt stack table (IST) to allow maximum 7 different exceptions to have
new stack for its handler. IA32 doesn't have IST mechanism and can only use
task gate to do it since task switch allows to load a new stack through its
task-state segment (TSS).
The new API, InitializeCpuExceptionHandlersEx, is implemented to complete
extra initialization for stack switch of exception handler. Since setting
up stack switch needs allocating new memory for new stack, new GDT table
and task-state segment but the initialization method will be called in
different phases which have no consistent way to reserve those memory, this
new API is allowed to pass the reserved resources to complete the extra
works. This is cannot be done by original InitializeCpuExceptionHandlers.
Considering exception handler initialization for MP situation, this new API
is also necessary, because AP is not supposed to allocate memory. So the
memory needed for stack switch have to be reserved in BSP before waking up
AP and then pass them to InitializeCpuExceptionHandlersEx afterwards.
Since Stack Guard feature is available only for DXE phase at this time, the
new API is fully implemented for DXE only. Other phases implement a dummy
one which just calls InitializeCpuExceptionHandlers().
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jeff Fan <vanjeff_919@hotmail.com>
Reviewed-by: Jiewen.yao@intel.com
2017-12-07 13:15:12 +01:00
|
|
|
|
2016-05-24 15:31:11 +02:00
|
|
|
/**
|
|
|
|
Common exception handler.
|
|
|
|
|
|
|
|
@param ExceptionType Exception type.
|
|
|
|
@param SystemContext Pointer to EFI_SYSTEM_CONTEXT.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
CommonExceptionHandler (
|
2017-04-07 04:00:59 +02:00
|
|
|
IN EFI_EXCEPTION_TYPE ExceptionType,
|
2016-05-24 15:31:11 +02:00
|
|
|
IN EFI_SYSTEM_CONTEXT SystemContext
|
|
|
|
)
|
|
|
|
{
|
|
|
|
CommonExceptionHandlerWorker (ExceptionType, SystemContext, &mExceptionHandlerData);
|
|
|
|
}
|
|
|
|
|
2013-11-22 07:24:41 +01:00
|
|
|
/**
|
|
|
|
Initializes all CPU exceptions entries and provides the default exception handlers.
|
2017-04-07 04:00:59 +02:00
|
|
|
|
2013-11-22 07:24:41 +01:00
|
|
|
Caller should try to get an array of interrupt and/or exception vectors that are in use and need to
|
|
|
|
persist by EFI_VECTOR_HANDOFF_INFO defined in PI 1.3 specification.
|
2017-04-07 04:00:59 +02:00
|
|
|
If caller cannot get reserved vector list or it does not exists, set VectorInfo to NULL.
|
2013-11-22 07:24:41 +01:00
|
|
|
If VectorInfo is not NULL, the exception vectors will be initialized per vector attribute accordingly.
|
|
|
|
|
|
|
|
@param[in] VectorInfo Pointer to reserved vector list.
|
2017-04-07 04:00:59 +02:00
|
|
|
|
|
|
|
@retval EFI_SUCCESS CPU Exception Entries have been successfully initialized
|
2013-11-22 07:24:41 +01:00
|
|
|
with default exception handlers.
|
|
|
|
@retval EFI_INVALID_PARAMETER VectorInfo includes the invalid content if VectorInfo is not NULL.
|
|
|
|
@retval EFI_UNSUPPORTED This function is not supported.
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
InitializeCpuExceptionHandlers (
|
|
|
|
IN EFI_VECTOR_HANDOFF_INFO *VectorInfo OPTIONAL
|
|
|
|
)
|
|
|
|
{
|
2016-05-24 15:00:02 +02:00
|
|
|
InitializeSpinLock (&mExceptionHandlerData.DisplayMessageSpinLock);
|
|
|
|
return InitializeCpuExceptionHandlersWorker (VectorInfo, &mExceptionHandlerData);
|
2013-11-22 07:24:41 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Registers a function to be called from the processor interrupt handler.
|
|
|
|
|
2017-04-07 04:00:59 +02:00
|
|
|
This function registers and enables the handler specified by InterruptHandler for a processor
|
|
|
|
interrupt or exception type specified by InterruptType. If InterruptHandler is NULL, then the
|
|
|
|
handler for the processor interrupt or exception type specified by InterruptType is uninstalled.
|
2013-11-22 07:24:41 +01:00
|
|
|
The installed handler is called once for each processor interrupt or exception.
|
2022-05-18 11:51:21 +02:00
|
|
|
NOTE: This function should be invoked after InitializeCpuExceptionHandlers() is invoked,
|
|
|
|
otherwise EFI_UNSUPPORTED returned.
|
2013-11-22 07:24:41 +01:00
|
|
|
|
|
|
|
@param[in] InterruptType Defines which interrupt or exception to hook.
|
|
|
|
@param[in] InterruptHandler A pointer to a function of type EFI_CPU_INTERRUPT_HANDLER that is called
|
|
|
|
when a processor interrupt occurs. If this parameter is NULL, then the handler
|
|
|
|
will be uninstalled.
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS The handler for the processor interrupt was successfully installed or uninstalled.
|
|
|
|
@retval EFI_ALREADY_STARTED InterruptHandler is not NULL, and a handler for InterruptType was
|
|
|
|
previously installed.
|
|
|
|
@retval EFI_INVALID_PARAMETER InterruptHandler is NULL, and a handler for InterruptType was not
|
|
|
|
previously installed.
|
|
|
|
@retval EFI_UNSUPPORTED The interrupt specified by InterruptType is not supported,
|
|
|
|
or this function is not supported.
|
2013-12-06 02:13:11 +01:00
|
|
|
**/
|
2013-11-22 07:24:41 +01:00
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
RegisterCpuInterruptHandler (
|
|
|
|
IN EFI_EXCEPTION_TYPE InterruptType,
|
|
|
|
IN EFI_CPU_INTERRUPT_HANDLER InterruptHandler
|
|
|
|
)
|
|
|
|
{
|
2016-05-24 15:25:17 +02:00
|
|
|
return RegisterCpuInterruptHandlerWorker (InterruptType, InterruptHandler, &mExceptionHandlerData);
|
2013-11-22 07:24:41 +01:00
|
|
|
}
|
UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
If Stack Guard is enabled and there's really a stack overflow happened during
boot, a Page Fault exception will be triggered. Because the stack is out of
usage, the exception handler, which shares the stack with normal UEFI driver,
cannot be executed and cannot dump the processor information.
Without those information, it's very difficult for the BIOS developers locate
the root cause of stack overflow. And without a workable stack, the developer
cannot event use single step to debug the UEFI driver with JTAG debugger.
In order to make sure the exception handler to execute normally after stack
overflow. We need separate stacks for exception handlers in case of unusable
stack.
IA processor allows to switch to a new stack during handling interrupt and
exception. But X64 and IA32 provides different ways to make it. X64 provides
interrupt stack table (IST) to allow maximum 7 different exceptions to have
new stack for its handler. IA32 doesn't have IST mechanism and can only use
task gate to do it since task switch allows to load a new stack through its
task-state segment (TSS).
The new API, InitializeCpuExceptionHandlersEx, is implemented to complete
extra initialization for stack switch of exception handler. Since setting
up stack switch needs allocating new memory for new stack, new GDT table
and task-state segment but the initialization method will be called in
different phases which have no consistent way to reserve those memory, this
new API is allowed to pass the reserved resources to complete the extra
works. This is cannot be done by original InitializeCpuExceptionHandlers.
Considering exception handler initialization for MP situation, this new API
is also necessary, because AP is not supposed to allocate memory. So the
memory needed for stack switch have to be reserved in BSP before waking up
AP and then pass them to InitializeCpuExceptionHandlersEx afterwards.
Since Stack Guard feature is available only for DXE phase at this time, the
new API is fully implemented for DXE only. Other phases implement a dummy
one which just calls InitializeCpuExceptionHandlers().
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jeff Fan <vanjeff_919@hotmail.com>
Reviewed-by: Jiewen.yao@intel.com
2017-12-07 13:15:12 +01:00
|
|
|
|
|
|
|
/**
|
2022-05-20 13:12:35 +02:00
|
|
|
Setup separate stacks for certain exception handlers.
|
2022-08-09 03:25:35 +02:00
|
|
|
If the input Buffer and BufferSize are both NULL, use global variable if possible.
|
UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
If Stack Guard is enabled and there's really a stack overflow happened during
boot, a Page Fault exception will be triggered. Because the stack is out of
usage, the exception handler, which shares the stack with normal UEFI driver,
cannot be executed and cannot dump the processor information.
Without those information, it's very difficult for the BIOS developers locate
the root cause of stack overflow. And without a workable stack, the developer
cannot event use single step to debug the UEFI driver with JTAG debugger.
In order to make sure the exception handler to execute normally after stack
overflow. We need separate stacks for exception handlers in case of unusable
stack.
IA processor allows to switch to a new stack during handling interrupt and
exception. But X64 and IA32 provides different ways to make it. X64 provides
interrupt stack table (IST) to allow maximum 7 different exceptions to have
new stack for its handler. IA32 doesn't have IST mechanism and can only use
task gate to do it since task switch allows to load a new stack through its
task-state segment (TSS).
The new API, InitializeCpuExceptionHandlersEx, is implemented to complete
extra initialization for stack switch of exception handler. Since setting
up stack switch needs allocating new memory for new stack, new GDT table
and task-state segment but the initialization method will be called in
different phases which have no consistent way to reserve those memory, this
new API is allowed to pass the reserved resources to complete the extra
works. This is cannot be done by original InitializeCpuExceptionHandlers.
Considering exception handler initialization for MP situation, this new API
is also necessary, because AP is not supposed to allocate memory. So the
memory needed for stack switch have to be reserved in BSP before waking up
AP and then pass them to InitializeCpuExceptionHandlersEx afterwards.
Since Stack Guard feature is available only for DXE phase at this time, the
new API is fully implemented for DXE only. Other phases implement a dummy
one which just calls InitializeCpuExceptionHandlers().
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jeff Fan <vanjeff_919@hotmail.com>
Reviewed-by: Jiewen.yao@intel.com
2017-12-07 13:15:12 +01:00
|
|
|
|
2022-08-09 03:25:35 +02:00
|
|
|
@param[in] Buffer Point to buffer used to separate exception stack.
|
|
|
|
@param[in, out] BufferSize On input, it indicates the byte size of Buffer.
|
|
|
|
If the size is not enough, the return status will
|
|
|
|
be EFI_BUFFER_TOO_SMALL, and output BufferSize
|
|
|
|
will be the size it needs.
|
UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
If Stack Guard is enabled and there's really a stack overflow happened during
boot, a Page Fault exception will be triggered. Because the stack is out of
usage, the exception handler, which shares the stack with normal UEFI driver,
cannot be executed and cannot dump the processor information.
Without those information, it's very difficult for the BIOS developers locate
the root cause of stack overflow. And without a workable stack, the developer
cannot event use single step to debug the UEFI driver with JTAG debugger.
In order to make sure the exception handler to execute normally after stack
overflow. We need separate stacks for exception handlers in case of unusable
stack.
IA processor allows to switch to a new stack during handling interrupt and
exception. But X64 and IA32 provides different ways to make it. X64 provides
interrupt stack table (IST) to allow maximum 7 different exceptions to have
new stack for its handler. IA32 doesn't have IST mechanism and can only use
task gate to do it since task switch allows to load a new stack through its
task-state segment (TSS).
The new API, InitializeCpuExceptionHandlersEx, is implemented to complete
extra initialization for stack switch of exception handler. Since setting
up stack switch needs allocating new memory for new stack, new GDT table
and task-state segment but the initialization method will be called in
different phases which have no consistent way to reserve those memory, this
new API is allowed to pass the reserved resources to complete the extra
works. This is cannot be done by original InitializeCpuExceptionHandlers.
Considering exception handler initialization for MP situation, this new API
is also necessary, because AP is not supposed to allocate memory. So the
memory needed for stack switch have to be reserved in BSP before waking up
AP and then pass them to InitializeCpuExceptionHandlersEx afterwards.
Since Stack Guard feature is available only for DXE phase at this time, the
new API is fully implemented for DXE only. Other phases implement a dummy
one which just calls InitializeCpuExceptionHandlers().
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jeff Fan <vanjeff_919@hotmail.com>
Reviewed-by: Jiewen.yao@intel.com
2017-12-07 13:15:12 +01:00
|
|
|
|
2022-05-20 13:12:35 +02:00
|
|
|
@retval EFI_SUCCESS The stacks are assigned successfully.
|
|
|
|
@retval EFI_UNSUPPORTED This function is not supported.
|
2022-08-09 03:25:35 +02:00
|
|
|
@retval EFI_BUFFER_TOO_SMALL This BufferSize is too small.
|
UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
If Stack Guard is enabled and there's really a stack overflow happened during
boot, a Page Fault exception will be triggered. Because the stack is out of
usage, the exception handler, which shares the stack with normal UEFI driver,
cannot be executed and cannot dump the processor information.
Without those information, it's very difficult for the BIOS developers locate
the root cause of stack overflow. And without a workable stack, the developer
cannot event use single step to debug the UEFI driver with JTAG debugger.
In order to make sure the exception handler to execute normally after stack
overflow. We need separate stacks for exception handlers in case of unusable
stack.
IA processor allows to switch to a new stack during handling interrupt and
exception. But X64 and IA32 provides different ways to make it. X64 provides
interrupt stack table (IST) to allow maximum 7 different exceptions to have
new stack for its handler. IA32 doesn't have IST mechanism and can only use
task gate to do it since task switch allows to load a new stack through its
task-state segment (TSS).
The new API, InitializeCpuExceptionHandlersEx, is implemented to complete
extra initialization for stack switch of exception handler. Since setting
up stack switch needs allocating new memory for new stack, new GDT table
and task-state segment but the initialization method will be called in
different phases which have no consistent way to reserve those memory, this
new API is allowed to pass the reserved resources to complete the extra
works. This is cannot be done by original InitializeCpuExceptionHandlers.
Considering exception handler initialization for MP situation, this new API
is also necessary, because AP is not supposed to allocate memory. So the
memory needed for stack switch have to be reserved in BSP before waking up
AP and then pass them to InitializeCpuExceptionHandlersEx afterwards.
Since Stack Guard feature is available only for DXE phase at this time, the
new API is fully implemented for DXE only. Other phases implement a dummy
one which just calls InitializeCpuExceptionHandlers().
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jeff Fan <vanjeff_919@hotmail.com>
Reviewed-by: Jiewen.yao@intel.com
2017-12-07 13:15:12 +01:00
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
2022-05-20 13:12:35 +02:00
|
|
|
InitializeSeparateExceptionStacks (
|
2022-08-09 03:25:35 +02:00
|
|
|
IN VOID *Buffer,
|
|
|
|
IN OUT UINTN *BufferSize
|
UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
If Stack Guard is enabled and there's really a stack overflow happened during
boot, a Page Fault exception will be triggered. Because the stack is out of
usage, the exception handler, which shares the stack with normal UEFI driver,
cannot be executed and cannot dump the processor information.
Without those information, it's very difficult for the BIOS developers locate
the root cause of stack overflow. And without a workable stack, the developer
cannot event use single step to debug the UEFI driver with JTAG debugger.
In order to make sure the exception handler to execute normally after stack
overflow. We need separate stacks for exception handlers in case of unusable
stack.
IA processor allows to switch to a new stack during handling interrupt and
exception. But X64 and IA32 provides different ways to make it. X64 provides
interrupt stack table (IST) to allow maximum 7 different exceptions to have
new stack for its handler. IA32 doesn't have IST mechanism and can only use
task gate to do it since task switch allows to load a new stack through its
task-state segment (TSS).
The new API, InitializeCpuExceptionHandlersEx, is implemented to complete
extra initialization for stack switch of exception handler. Since setting
up stack switch needs allocating new memory for new stack, new GDT table
and task-state segment but the initialization method will be called in
different phases which have no consistent way to reserve those memory, this
new API is allowed to pass the reserved resources to complete the extra
works. This is cannot be done by original InitializeCpuExceptionHandlers.
Considering exception handler initialization for MP situation, this new API
is also necessary, because AP is not supposed to allocate memory. So the
memory needed for stack switch have to be reserved in BSP before waking up
AP and then pass them to InitializeCpuExceptionHandlersEx afterwards.
Since Stack Guard feature is available only for DXE phase at this time, the
new API is fully implemented for DXE only. Other phases implement a dummy
one which just calls InitializeCpuExceptionHandlers().
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jeff Fan <vanjeff_919@hotmail.com>
Reviewed-by: Jiewen.yao@intel.com
2017-12-07 13:15:12 +01:00
|
|
|
)
|
|
|
|
{
|
2022-08-26 09:04:47 +02:00
|
|
|
UINTN LocalBufferSize;
|
|
|
|
EFI_STATUS Status;
|
|
|
|
|
2022-08-09 03:25:35 +02:00
|
|
|
if ((Buffer == NULL) && (BufferSize == NULL)) {
|
2022-08-26 09:04:47 +02:00
|
|
|
SetMem (mBuffer, sizeof (mBuffer), 0);
|
|
|
|
LocalBufferSize = sizeof (mBuffer);
|
|
|
|
Status = ArchSetupExceptionStack (mBuffer, &LocalBufferSize);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
return Status;
|
2022-08-09 03:25:35 +02:00
|
|
|
} else {
|
2022-08-26 09:04:47 +02:00
|
|
|
return ArchSetupExceptionStack (Buffer, BufferSize);
|
UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
If Stack Guard is enabled and there's really a stack overflow happened during
boot, a Page Fault exception will be triggered. Because the stack is out of
usage, the exception handler, which shares the stack with normal UEFI driver,
cannot be executed and cannot dump the processor information.
Without those information, it's very difficult for the BIOS developers locate
the root cause of stack overflow. And without a workable stack, the developer
cannot event use single step to debug the UEFI driver with JTAG debugger.
In order to make sure the exception handler to execute normally after stack
overflow. We need separate stacks for exception handlers in case of unusable
stack.
IA processor allows to switch to a new stack during handling interrupt and
exception. But X64 and IA32 provides different ways to make it. X64 provides
interrupt stack table (IST) to allow maximum 7 different exceptions to have
new stack for its handler. IA32 doesn't have IST mechanism and can only use
task gate to do it since task switch allows to load a new stack through its
task-state segment (TSS).
The new API, InitializeCpuExceptionHandlersEx, is implemented to complete
extra initialization for stack switch of exception handler. Since setting
up stack switch needs allocating new memory for new stack, new GDT table
and task-state segment but the initialization method will be called in
different phases which have no consistent way to reserve those memory, this
new API is allowed to pass the reserved resources to complete the extra
works. This is cannot be done by original InitializeCpuExceptionHandlers.
Considering exception handler initialization for MP situation, this new API
is also necessary, because AP is not supposed to allocate memory. So the
memory needed for stack switch have to be reserved in BSP before waking up
AP and then pass them to InitializeCpuExceptionHandlersEx afterwards.
Since Stack Guard feature is available only for DXE phase at this time, the
new API is fully implemented for DXE only. Other phases implement a dummy
one which just calls InitializeCpuExceptionHandlers().
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jeff Fan <vanjeff_919@hotmail.com>
Reviewed-by: Jiewen.yao@intel.com
2017-12-07 13:15:12 +01:00
|
|
|
}
|
|
|
|
}
|