On Aug 28, 2014, at 8:08 AM, Laszlo Ersek <[email protected]> wrote:
> On 08/28/14 16:52, Peter Maydell wrote:
>> On 28 August 2014 15:30, Laszlo Ersek <[email protected]> wrote:
>>> So we got, in the NOR-mapped FD file:
>>>
>>> address 0: jump instruction to 4K, otherwise a bunch of emptiness
>>> (according to erase polarity!)
>>
>> Ideally this should be a proper complete vector table with
>> handlers for all the exception vectors. In particular it is a
>> nice touch if exceptions for things like invalid accesses
>> and undefined instructions end up in some sort of panic-abort
>> function that dumps a diagnostic message to the UART.
>> This isn't necessary for proper operation but it's handy if
>> you're trying to debug either UEFI itself or early kernel startup.
>> As a minimum you want to have them go somewhere sensible
>> (like a jump-to-self instruction) so that we definitely don't just
>> try to reenter UEFI at its start point (an effect that is more
>> likely in 32-bit ARM where the all-zeroes instruction is a NOP).
>>
>> Does UEFI install a proper vector table at some point in
>> bootup by writing to the vector base address register?
>
For x86 protected and long mode there is not a fixed address for the vectors.
It is setup via an instruction.
You can see the code setting up exceptions by searching for the BaseLib
function to write lidt.
~/work/src/edk2(master)>git grep AsmWriteIdtr
EdkCompatibilityPkg/Compatibility/BootScriptSaveOnS3SaveStateThunk/X64/DispatchExecute.c:139:
AsmWriteIdtr (Ia32Idtr);
EdkCompatibilityPkg/Compatibility/BootScriptSaveOnS3SaveStateThunk/X64/DispatchExecute.c:153:
AsmWriteIdtr ((IA32_DESCRIPTOR *) &X64Idtr);
EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Include/Library/EdkIIGlueBaseLib.h:6467:AsmWriteIdtr
(
EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Library/BaseLib/Ia32/WriteIdtr.asm:18:;
AsmWriteIdtr function
EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Library/BaseLib/Ia32/WriteIdtr.c:2:
AsmWriteIdtr function
EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Library/BaseLib/X64/WriteIdtr.S:18:#
AsmWriteIdtr function
EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Library/BaseLib/X64/WriteIdtr.asm:16:;
AsmWriteIdtr function
EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Library/BaseLib/X86WriteIdtr.c:38:AsmWriteIdtr
(
IntelFspPkg/FspSecCore/SecMain.c:101: AsmWriteIdtr (&IdtDescriptor);
IntelFspPkg/FspSecCore/SecMain.c:192: AsmWriteIdtr (&IdtDescriptor);
IntelFspWrapperPkg/FspInitPei/SecMain.c:121: AsmWriteIdtr (&IdtDescriptor);
IntelFspWrapperPkg/FspWrapperSecCore/SecMain.c:116: AsmWriteIdtr
(&IdtDescriptor);
IntelFspWrapperPkg/Library/SecPeiFspPlatformSecLibSample/SecTempRamSupport.c:133:
AsmWriteIdtr (&IdtDescriptor);
MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c:172: AsmWriteIdtr
(&gLidtDescriptor);
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/IA32/SetIdtEntry.c:39:
AsmWriteIdtr (IdtDescriptor);
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/SetIdtEntry.c:102:
AsmWriteIdtr (IdtDescriptor);
MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c:56: AsmWriteIdtr
((IA32_DESCRIPTOR *) &X64Idtr);
MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c:88: AsmWriteIdtr
((IA32_DESCRIPTOR *) &Ia32Idtr);
MdePkg/Include/Library/BaseLib.h:6498:AsmWriteIdtr (
MdePkg/Library/BaseLib/Ia32/WriteIdtr.asm:18:; AsmWriteIdtr function
MdePkg/Library/BaseLib/Ia32/WriteIdtr.c:2: AsmWriteIdtr function
MdePkg/Library/BaseLib/X64/WriteIdtr.asm:18:; AsmWriteIdtr function
MdePkg/Library/BaseLib/X86WriteIdtr.c:2: IA-32/x64 AsmWriteIdtr()
MdePkg/Library/BaseLib/X86WriteIdtr.c:33:AsmWriteIdtr (
MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointer.c:126:
AsmWriteIdtr (&Idtr);
OvmfPkg/Library/LoadLinuxLib/LinuxGdt.c:179: AsmWriteIdtr (&IdtPtr);
OvmfPkg/Sec/SecMain.c:726: AsmWriteIdtr (&IdtDescriptor);
OvmfPkg/Sec/SecMain.c:873: AsmWriteIdtr (&IdtDescriptor);
SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgent/DxeDebugAgentLib.c:278:
AsmWriteIdtr ((IA32_DESCRIPTOR *) &Idtr);
SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgent/DxeDebugAgentLib.c:479:
AsmWriteIdtr (&IdtDescriptor);
SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgent/SmmDebugAgentLib.c:327:
AsmWriteIdtr ((IA32_DESCRIPTOR *) &Idtr);
UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c:134: AsmWriteIdtr
((IA32_DESCRIPTOR *) &IdtDescriptor);
UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuException.c:56: IDTR
by AsmWriteIdtr().
UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c:453: AsmWriteIdtr
(&PeiS3ResumeState->Idtr);
> Yes, it does that on x86_64 / OVMF. (The feature comes from UefiCpuPkg.)
> The exception type & details (registers etc) are dumped, and even the
> offending binary file and RIP are identified in a way that allows one to
> correlate the exception with the source code.
>
> However:
> - I have no clue if anything similar exists in / for ARM builds.
>
> - Even if someone wants to implement such, where should (where *can*,
> actually) the exception handler table exist at all? The addresses
> that I listed above are backed by the (read-only) flash chip. The
> exception handler table should be built somewhere in DRAM, no?
>
>> If
>> not then providing a sensible initial set of vectors is even
>> more important.
>
> Hmmm, wait a second, now grepping for CpuExceptionHandlerLib, I'm
> actually getting results from ARM packages as well. Ard's series
> resolves this library class to:
>
>
> CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
>
> Ugh, that's a null library instance; it does nothing. :( If it's any
> consolation, "ArmVExpress.dsc.inc" seems to use the same, for the
> physical platforms.
>
> ... Hm, maybe I'm looking in the wrong place. ARM likely doesn't
> actually use CpuExceptionHandlerLib for handling CPU expcetions.
>
> There's this code though:
>
> ArmPkg/Drivers/CpuDxe/AArch64/Exception.c
>
> I think it covers exactly what you say (or at least participates in it).
> People have even submitted patches against it (see git commit 6a343fac
> for example.) I'm quite sure the feature you named is covered, but
> Olivier should be able to state authoritatively.
>
> Thanks
> Laszlo
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
