* Clarification about InitializeCpuExceptionHandlers() and TGE bit in hcr_el2
@ 2017-09-28 11:23 Vabhav Sharma
2017-09-28 14:00 ` Andrew Fish
0 siblings, 1 reply; 6+ messages in thread
From: Vabhav Sharma @ 2017-09-28 11:23 UTC (permalink / raw)
To: edk2-devel@lists.01.org, edk2-devel
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?
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Clarification about InitializeCpuExceptionHandlers() and TGE bit in hcr_el2
2017-09-28 11:23 Clarification about InitializeCpuExceptionHandlers() and TGE bit in hcr_el2 Vabhav Sharma
@ 2017-09-28 14:00 ` Andrew Fish
2017-10-05 16:53 ` Vabhav Sharma
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Fish @ 2017-09-28 14:00 UTC (permalink / raw)
To: Vabhav Sharma; +Cc: edk2-devel@lists.01.org, edk2-devel
> On Sep 28, 2017, at 4:23 AM, Vabhav Sharma <vabhav.sharma@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
> https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Clarification about InitializeCpuExceptionHandlers() and TGE bit in hcr_el2
2017-09-28 14:00 ` Andrew Fish
@ 2017-10-05 16:53 ` Vabhav Sharma
2017-10-05 17:02 ` Andrew Fish
0 siblings, 1 reply; 6+ messages in thread
From: Vabhav Sharma @ 2017-10-05 16:53 UTC (permalink / raw)
To: afish@apple.com, Ard Biesheuvel; +Cc: edk2-devel@lists.01.org
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?
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: afish@apple.com [mailto:afish@apple.com]
Sent: Thursday, September 28, 2017 7:31 PM
To: Vabhav Sharma <vabhav.sharma@nxp.com>
Cc: edk2-devel@lists.01.org; edk2-devel <edk2-devel-bounces@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.sharma@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
> https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Clarification about InitializeCpuExceptionHandlers() and TGE bit in hcr_el2
2017-10-05 16:53 ` Vabhav Sharma
@ 2017-10-05 17:02 ` Andrew Fish
2017-10-05 17:14 ` Vabhav Sharma
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Fish @ 2017-10-05 17:02 UTC (permalink / raw)
To: Vabhav Sharma; +Cc: Ard Biesheuvel, edk2-devel@lists.01.org
> On Oct 5, 2017, at 9:53 AM, Vabhav Sharma <vabhav.sharma@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: afish@apple.com [mailto:afish@apple.com]
> Sent: Thursday, September 28, 2017 7:31 PM
> To: Vabhav Sharma <vabhav.sharma@nxp.com>
> Cc: edk2-devel@lists.01.org; edk2-devel <edk2-devel-bounces@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.sharma@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
>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Clarification about InitializeCpuExceptionHandlers() and TGE bit in hcr_el2
2017-10-05 17:02 ` Andrew Fish
@ 2017-10-05 17:14 ` Vabhav Sharma
2017-10-05 17:20 ` Andrew Fish
0 siblings, 1 reply; 6+ messages in thread
From: Vabhav Sharma @ 2017-10-05 17:14 UTC (permalink / raw)
To: afish@apple.com; +Cc: Ard Biesheuvel, edk2-devel@lists.01.org
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: afish@apple.com [mailto:afish@apple.com]
Sent: Thursday, October 05, 2017 10:32 PM
To: Vabhav Sharma <vabhav.sharma@nxp.com>
Cc: Ard Biesheuvel <ard.biesheuvel@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.sharma@nxp.com<mailto:vabhav.sharma@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: afish@apple.com<mailto:afish@apple.com> [mailto:afish@apple.com]
Sent: Thursday, September 28, 2017 7:31 PM
To: Vabhav Sharma <vabhav.sharma@nxp.com<mailto:vabhav.sharma@nxp.com>>
Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; edk2-devel <edk2-devel-bounces@lists.01.org<mailto:edk2-devel-bounces@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.sharma@nxp.com<mailto:vabhav.sharma@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Clarification about InitializeCpuExceptionHandlers() and TGE bit in hcr_el2
2017-10-05 17:14 ` Vabhav Sharma
@ 2017-10-05 17:20 ` Andrew Fish
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Fish @ 2017-10-05 17:20 UTC (permalink / raw)
To: Vabhav Sharma; +Cc: edk2-devel@lists.01.org, Ard Biesheuvel
> On Oct 5, 2017, at 10:14 AM, Vabhav Sharma <vabhav.sharma@nxp.com> wrote:
>
> 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?
>
Vabhav,
Generally x86 starts from SEC as it contains the traditional x86 reset vector of 0xFFFFFFF0.
Thanks,
Andrew Fish
> Regards,
> Vabhav
>
> From: afish@apple.com [mailto:afish@apple.com]
> Sent: Thursday, October 05, 2017 10:32 PM
> To: Vabhav Sharma <vabhav.sharma@nxp.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@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.sharma@nxp.com<mailto:vabhav.sharma@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: afish@apple.com<mailto:afish@apple.com> [mailto:afish@apple.com]
> Sent: Thursday, September 28, 2017 7:31 PM
> To: Vabhav Sharma <vabhav.sharma@nxp.com<mailto:vabhav.sharma@nxp.com>>
> Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; edk2-devel <edk2-devel-bounces@lists.01.org<mailto:edk2-devel-bounces@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.sharma@nxp.com<mailto:vabhav.sharma@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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-10-05 17:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-28 11:23 Clarification about InitializeCpuExceptionHandlers() and TGE bit in hcr_el2 Vabhav Sharma
2017-09-28 14:00 ` Andrew Fish
2017-10-05 16:53 ` Vabhav Sharma
2017-10-05 17:02 ` Andrew Fish
2017-10-05 17:14 ` Vabhav Sharma
2017-10-05 17:20 ` Andrew Fish
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox