audk/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h

167 lines
5.6 KiB
C
Raw Normal View History

/** @file
CPU Exception library provides the default CPU interrupt/exception handler.
It also provides capability to register user interrupt/exception handler.
Copyright (c) 2012 - 2022, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
#ifndef __CPU_EXCEPTION_HANDLER_LIB_H__
#define __CPU_EXCEPTION_HANDLER_LIB_H__
#include <Ppi/VectorHandoffInfo.h>
#include <Protocol/Cpu.h>
#define CPU_EXCEPTION_INIT_DATA_REV 1
typedef union {
struct {
//
// Revision number of this structure.
//
UINT32 Revision;
//
// The address of top of known good stack reserved for *ALL* exceptions
// listed in field StackSwitchExceptions.
//
UINTN KnownGoodStackTop;
//
// The size of known good stack for *ONE* exception only.
//
UINTN KnownGoodStackSize;
//
// Buffer of exception vector list for stack switch.
//
UINT8 *StackSwitchExceptions;
//
// Number of exception vectors in StackSwitchExceptions.
//
UINTN StackSwitchExceptionNumber;
//
// Buffer of IDT table. It must be type of IA32_IDT_GATE_DESCRIPTOR.
// Normally there's no need to change IDT table size.
//
VOID *IdtTable;
//
// Size of buffer for IdtTable.
//
UINTN IdtTableSize;
//
// Buffer of GDT table. It must be type of IA32_SEGMENT_DESCRIPTOR.
//
VOID *GdtTable;
//
// Size of buffer for GdtTable.
//
UINTN GdtTableSize;
//
// Pointer to start address of descriptor of exception task gate in the
// GDT table. It must be type of IA32_TSS_DESCRIPTOR.
//
VOID *ExceptionTssDesc;
//
// Size of buffer for ExceptionTssDesc.
//
UINTN ExceptionTssDescSize;
//
// Buffer of task-state segment for exceptions. It must be type of
// IA32_TASK_STATE_SEGMENT.
//
VOID *ExceptionTss;
//
// Size of buffer for ExceptionTss.
//
UINTN ExceptionTssSize;
//
// Flag to indicate if default handlers should be initialized or not.
//
BOOLEAN InitDefaultHandlers;
} Ia32, X64;
} CPU_EXCEPTION_INIT_DATA;
/**
Initializes all CPU exceptions entries and provides the default exception handlers.
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.
If caller cannot get reserved vector list or it does not exists, set VectorInfo to NULL.
If VectorInfo is not NULL, the exception vectors will be initialized per vector attribute accordingly.
@param[in] VectorInfo Pointer to reserved vector list.
@retval EFI_SUCCESS CPU Exception Entries have been successfully initialized
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
);
/**
CpuException: Add InitializeSeparateExceptionStacks Today InitializeCpuExceptionHandlersEx is called from three modules: 1. DxeCore (links to DxeCpuExceptionHandlerLib) DxeCore expects it initializes the IDT entries as well as assigning separate stacks for #DF and #PF. 2. CpuMpPei (links to PeiCpuExceptionHandlerLib) and CpuDxe (links to DxeCpuExceptionHandlerLib) It's called for each thread for only assigning separate stacks for #DF and #PF. The IDT entries initialization is skipped because caller sets InitData->X64.InitDefaultHandlers to FALSE. Additionally, SecPeiCpuExceptionHandlerLib, SmmCpuExceptionHandlerLib also implement such API and the behavior of the API is simply to initialize IDT entries only. Because it mixes the IDT entries initialization and separate stacks assignment for certain exception handlers together, in order to know whether the function call only initializes IDT entries, or assigns stacks, we need to check: 1. value of InitData->X64.InitDefaultHandlers 2. library instance This patch cleans up the code to separate the stack assignment to a new API: InitializeSeparateExceptionStacks(). Only when caller calls the new API, the separate stacks are assigned. With this change, the SecPei and Smm instance can return unsupported which gives caller a very clear status. The old API InitializeCpuExceptionHandlersEx() is removed in this patch. Because no platform module is consuming the old API, the impact is none. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com>
2022-05-20 13:12:35 +02:00
Setup separate stacks for certain exception handlers.
CpuException: Add InitializeSeparateExceptionStacks Today InitializeCpuExceptionHandlersEx is called from three modules: 1. DxeCore (links to DxeCpuExceptionHandlerLib) DxeCore expects it initializes the IDT entries as well as assigning separate stacks for #DF and #PF. 2. CpuMpPei (links to PeiCpuExceptionHandlerLib) and CpuDxe (links to DxeCpuExceptionHandlerLib) It's called for each thread for only assigning separate stacks for #DF and #PF. The IDT entries initialization is skipped because caller sets InitData->X64.InitDefaultHandlers to FALSE. Additionally, SecPeiCpuExceptionHandlerLib, SmmCpuExceptionHandlerLib also implement such API and the behavior of the API is simply to initialize IDT entries only. Because it mixes the IDT entries initialization and separate stacks assignment for certain exception handlers together, in order to know whether the function call only initializes IDT entries, or assigns stacks, we need to check: 1. value of InitData->X64.InitDefaultHandlers 2. library instance This patch cleans up the code to separate the stack assignment to a new API: InitializeSeparateExceptionStacks(). Only when caller calls the new API, the separate stacks are assigned. With this change, the SecPei and Smm instance can return unsupported which gives caller a very clear status. The old API InitializeCpuExceptionHandlersEx() is removed in this patch. Because no platform module is consuming the old API, the impact is none. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com>
2022-05-20 13:12:35 +02:00
InitData is optional and processor arch dependent.
CpuException: Add InitializeSeparateExceptionStacks Today InitializeCpuExceptionHandlersEx is called from three modules: 1. DxeCore (links to DxeCpuExceptionHandlerLib) DxeCore expects it initializes the IDT entries as well as assigning separate stacks for #DF and #PF. 2. CpuMpPei (links to PeiCpuExceptionHandlerLib) and CpuDxe (links to DxeCpuExceptionHandlerLib) It's called for each thread for only assigning separate stacks for #DF and #PF. The IDT entries initialization is skipped because caller sets InitData->X64.InitDefaultHandlers to FALSE. Additionally, SecPeiCpuExceptionHandlerLib, SmmCpuExceptionHandlerLib also implement such API and the behavior of the API is simply to initialize IDT entries only. Because it mixes the IDT entries initialization and separate stacks assignment for certain exception handlers together, in order to know whether the function call only initializes IDT entries, or assigns stacks, we need to check: 1. value of InitData->X64.InitDefaultHandlers 2. library instance This patch cleans up the code to separate the stack assignment to a new API: InitializeSeparateExceptionStacks(). Only when caller calls the new API, the separate stacks are assigned. With this change, the SecPei and Smm instance can return unsupported which gives caller a very clear status. The old API InitializeCpuExceptionHandlersEx() is removed in this patch. Because no platform module is consuming the old API, the impact is none. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com>
2022-05-20 13:12:35 +02:00
@param[in] InitData Pointer to data optional for information about how
to assign stacks for certain exception handlers.
CpuException: Add InitializeSeparateExceptionStacks Today InitializeCpuExceptionHandlersEx is called from three modules: 1. DxeCore (links to DxeCpuExceptionHandlerLib) DxeCore expects it initializes the IDT entries as well as assigning separate stacks for #DF and #PF. 2. CpuMpPei (links to PeiCpuExceptionHandlerLib) and CpuDxe (links to DxeCpuExceptionHandlerLib) It's called for each thread for only assigning separate stacks for #DF and #PF. The IDT entries initialization is skipped because caller sets InitData->X64.InitDefaultHandlers to FALSE. Additionally, SecPeiCpuExceptionHandlerLib, SmmCpuExceptionHandlerLib also implement such API and the behavior of the API is simply to initialize IDT entries only. Because it mixes the IDT entries initialization and separate stacks assignment for certain exception handlers together, in order to know whether the function call only initializes IDT entries, or assigns stacks, we need to check: 1. value of InitData->X64.InitDefaultHandlers 2. library instance This patch cleans up the code to separate the stack assignment to a new API: InitializeSeparateExceptionStacks(). Only when caller calls the new API, the separate stacks are assigned. With this change, the SecPei and Smm instance can return unsupported which gives caller a very clear status. The old API InitializeCpuExceptionHandlersEx() is removed in this patch. Because no platform module is consuming the old API, the impact is none. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com>
2022-05-20 13:12:35 +02:00
@retval EFI_SUCCESS The stacks are assigned successfully.
@retval EFI_UNSUPPORTED This function is not supported.
**/
EFI_STATUS
EFIAPI
CpuException: Add InitializeSeparateExceptionStacks Today InitializeCpuExceptionHandlersEx is called from three modules: 1. DxeCore (links to DxeCpuExceptionHandlerLib) DxeCore expects it initializes the IDT entries as well as assigning separate stacks for #DF and #PF. 2. CpuMpPei (links to PeiCpuExceptionHandlerLib) and CpuDxe (links to DxeCpuExceptionHandlerLib) It's called for each thread for only assigning separate stacks for #DF and #PF. The IDT entries initialization is skipped because caller sets InitData->X64.InitDefaultHandlers to FALSE. Additionally, SecPeiCpuExceptionHandlerLib, SmmCpuExceptionHandlerLib also implement such API and the behavior of the API is simply to initialize IDT entries only. Because it mixes the IDT entries initialization and separate stacks assignment for certain exception handlers together, in order to know whether the function call only initializes IDT entries, or assigns stacks, we need to check: 1. value of InitData->X64.InitDefaultHandlers 2. library instance This patch cleans up the code to separate the stack assignment to a new API: InitializeSeparateExceptionStacks(). Only when caller calls the new API, the separate stacks are assigned. With this change, the SecPei and Smm instance can return unsupported which gives caller a very clear status. The old API InitializeCpuExceptionHandlersEx() is removed in this patch. Because no platform module is consuming the old API, the impact is none. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com>
2022-05-20 13:12:35 +02:00
InitializeSeparateExceptionStacks (
IN CPU_EXCEPTION_INIT_DATA *InitData OPTIONAL
);
/**
Registers a function to be called from the processor interrupt handler.
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.
The installed handler is called once for each processor interrupt or exception.
NOTE: This function should be invoked after InitializeCpuExceptionHandlers() is invoked,
otherwise EFI_UNSUPPORTED returned.
@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.
**/
EFI_STATUS
EFIAPI
RegisterCpuInterruptHandler (
IN EFI_EXCEPTION_TYPE InterruptType,
IN EFI_CPU_INTERRUPT_HANDLER InterruptHandler
);
/**
Display processor context.
@param[in] ExceptionType Exception type.
@param[in] SystemContext Processor context to be display.
**/
VOID
EFIAPI
DumpCpuContext (
IN EFI_EXCEPTION_TYPE ExceptionType,
IN EFI_SYSTEM_CONTEXT SystemContext
);
#endif