Andrew Fish, Yes catching the exception is very critical for debugging. Looks like, This is the model where edk2 starts from cold boot
As per ARM Platform documentation(ArmPlatformPkg\Documentation) edk2 starts from either cold boot(SEC Phase) or 2nd stage bootloader(Prepi Phase where Platform ROM code is 1st stage bootloader) and I don't see handlers are installed before dxemain. Does same model(edk2 from 2nd stage bootloader) exist for x86 as well? Regards, Vabhav From: af...@apple.com [mailto:af...@apple.com] Sent: Thursday, October 05, 2017 10:32 PM To: Vabhav Sharma <vabhav.sha...@nxp.com> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; edk2-devel@lists.01.org Subject: Re: [edk2] Clarification about InitializeCpuExceptionHandlers() and TGE bit in hcr_el2 On Oct 5, 2017, at 9:53 AM, Vabhav Sharma <vabhav.sha...@nxp.com<mailto:vabhav.sha...@nxp.com>> wrote: Thanks Andrew Fish, I understand. In PEI Phase, No handlers are installed and there might be pending exception. ExceptionHandlers() can be installed during PEI phase like after initializing the MMU to catch unhandled exception. Please suggest? Vabhav, It looks like for x86 InitializeCpuExceptionHandlers() is called in SEC and then in CPU PEIM calls InitializeCpuExceptionHandlers(). ~/work/src/edk2(master)>git grep InitializeCpuExceptionHandlers ArmPkg/Drivers/CpuDxe/Exception.c:37: InitializeCpuExceptionHandlers(VectorInfo); ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c:94:InitializeCpuExceptionHandlers( ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c:242:NOTE: This function should be invoked after InitializeCpuExceptionHandlers() or MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:261: Status = InitializeCpuExceptionHandlers (VectorInfoList); MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h:40:InitializeCpuExceptionHandlers ( MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h:73: NOTE: This function should be invoked after InitializeCpuExceptionHandlers() or MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.c:35:InitializeCpuExceptionHandlers ( MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.c:74: NOTE: This function should be invoked after InitializeCpuExceptionHandlers() or MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/IA32/SetIdtEntry.c:44: Status = InitializeCpuExceptionHandlers (NULL); MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/SetIdtEntry.c:155: Status = InitializeCpuExceptionHandlers (NULL); MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c:249: Status = InitializeCpuExceptionHandlers (NULL); UefiCpuPkg/CpuMpPei/CpuMpPei.c:447: Status = InitializeCpuExceptionHandlers (VectorInfo); UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h:158:InitializeCpuExceptionHandlersWorker ( UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c:62:InitializeCpuExceptionHandlers ( UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c:69: return InitializeCpuExceptionHandlersWorker (VectorInfo, &mExceptionHandlerData); UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c:175: NOTE: This function should be invoked after InitializeCpuExceptionHandlers() or UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c:88:InitializeCpuExceptionHandlers ( UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c:105: Status = InitializeCpuExceptionHandlersWorker (VectorInfo, ExceptionHandlerData); UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c:156: NOTE: This function should be invoked after InitializeCpuExceptionHandlers() or UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c:203:InitializeCpuExceptionHandlersWorker ( UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuException.c:64:InitializeCpuExceptionHandlers ( UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuException.c:155: NOTE: This function should be invoked after InitializeCpuExceptionHandlers() or UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c:62:InitializeCpuExceptionHandlers ( UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c:69: return InitializeCpuExceptionHandlersWorker (VectorInfo, &mExceptionHandlerData); UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmException.c:104: NOTE: This function should be invoked after InitializeCpuExceptionHandlers() or UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c:646: Status = InitializeCpuExceptionHandlers (NULL); UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c:157: Status = InitializeCpuExceptionHandlers (NULL); UefiCpuPkg/SecCore/SecMain.c:184: Status = InitializeCpuExceptionHandlers (NULL); At least on x86 the exceptions don't tend to pend, they just happen. So for example an ASSERT() macro can map to an INT 3 (Breakpoint) on x86, you can get GP faults for accessing a non-cononical address, etc. So catching the exception and printing out the PC, and stack trace if possible is very useful for debugging. Thanks, Andrew Fish Dear Arm Folks, I request you to comment on hcr_el2 usage mentioned in below email I understand that Enabling TGE bit will route the EL1 exception to EL2.Is there any EL1 code during UEFI execution? Regards, Vabhav -----Original Message----- From: af...@apple.com<mailto:af...@apple.com> [mailto:af...@apple.com] Sent: Thursday, September 28, 2017 7:31 PM To: Vabhav Sharma <vabhav.sha...@nxp.com<mailto:vabhav.sha...@nxp.com>> Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; edk2-devel <edk2-devel-boun...@lists.01.org<mailto:edk2-devel-boun...@lists.01.org>> Subject: Re: [edk2] Clarification about InitializeCpuExceptionHandlers() and TGE bit in hcr_el2 On Sep 28, 2017, at 4:23 AM, Vabhav Sharma <vabhav.sha...@nxp.com<mailto:vabhav.sha...@nxp.com>> wrote: Hi All, I see that InitializeCpuExceptionHandlers() is called from DxeMain to take over exception handlers and later from ArmCpuDxe. Is there any specific purpose to call it from two places during dxe phase? Vabhav, DxeMain is the DXE Core and that is like (micro) kernel and it is platform agnostic code. InitializeCpuExceptionHandlers() exists in that location to catch unhandled exceptions, especially in the case when no debugger stub is linked in. The CPU Dxe driver abstracts CPU specifics from the DXE Core and it adds supports for interrupts, cachability, etc. and the DXE Core uses services from this driver to abstract CPU implementation. To make things even more complex on some platforms PEI and DXE run in entirely different modes. For example on x86 is is common for PEI to be 32-bit and and DXE to be 64-bit. This is mostly due to how complex it is to turn on memory, and the fact that there is no good place to put the page tables prior to memory init. I'll let the ARM folks comment on hcr_el2 usage. Thanks, Andrew Fish Additionally we are setting TGE bit three times in hcr_el2 during PrePei phase(ArmPlatformPkg/PrePi/AArch64/ArchPrePi.c) and Twice in Dxe phase: dxemain(),ArmCpuDxe Please help to clarify or required to be fixed? Regards, Vabhav _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
