Andrew, For CPU Exception (0x0 to 0x31), CPU exception handler lib will dump CPU context and DeadLoop(). For CPU Interrupt (upper 0x31), CPU exception handler lib will invoke interrupt handler() if registered, otherwise it just restore CPU context and iret.
8259 may issue spurious interrupt (IRQ7) due to noise on the IRQ lines. Its vector is 0x68+7 that has not registered handler, we need to skip such case. Thanks! Jeff -----Original Message----- From: Scott Duplichan [mailto:[email protected]] Sent: Saturday, August 09, 2014 12:26 PM To: [email protected] Subject: Re: [edk2] [UefiCpuPkg] how did this ever work. Bill Paul [mailto:[email protected]] wrote: ]Of all the gin joints in all the towns in all the world, Andrew Fish had to ]walk into mine at 16:46:15 on Friday 08 August 2014 and say: ] ]> I’m still working on porting the CpuExceptionHandlerLib to clang, but I hit ]> some code I don’t understand? I have mods in the assembly code but….. ]> ]> I’m running in QEMU and I’m taking the 1st timer tick and ]> CommonExceptionHandler() gets called and ExceptionType is 0x68. But ]> ExceptionType is used to index into an array that only has 32 entries? ] ]Vectors 0 to 31 are reserved for internal CPU exception vector values when ]running in protected mode or long mode. Vectors 32 through 255 are available ]for software defined interrupts. ](In 16-bit real mode, only vectors 0 through 7 are reserved, A bit of trivia: As far back as 1979, real mode vectors 0-1Fh were documented as reserved (The 8086 Family User's Manual - 1979). It is surprising the 1981 IBM PC BIOS ignored this and used vectors 8-15 for the 8259 PIC. By the time the 80286 arrived, Intel had assigned new exceptions to some of the vectors in the 8-15 range. Today, some of these exceptions _can_ occur in real mode: 8, 12, 13, 16, 18, 19 (Intel 64 and IA-32 Architectures Software Developer’s Manual). So moving the master PIC out of the 8-15 vector range would be a good idea even in real mode. But this is not often done for real mode because real mode is not used much anymore. ]which requires you to fiddle with the 8259 PICs a bit when you ]enter protected mode to avoid a conflict in the unlikely event that ]you choose to use the legacy PICs for interrupt handling.) Maybe 'unlikely event' is not a good choice of words given x86 UEFI uses legacy PICs for interrupt handling. It would be interesting to see UEFI use APIC mode. I guess the need to support legacy option roms and csm would make that unworkable though. ]So the exception count is correct, and I guess CommonExceptionHandler() is ]assuming that the ExceptionType argument will only ever be an internal ]exception value. Presumably there's some other code somewhere that branches ]off the handling of vectors 32 to 255 to a different handler (for IRQ ]dispatching). ] ]The question is where is the value 0x68 coming from? Moving the master PIC to vector 0x68 to avoid overlapping processor exceptions is common practice, but who did it first? It might have been SoftLogic DoubleDos in the mid 1980's. By rebasing the PIC(s), DoubleDos was able to maintain its hardware interrupt hooks even when DOS applications replaced the vectors. Thanks, Scott ]-Bill ] ]> Thanks, ]> ]> Andrew Fish ]> ]> ]> ~/work/src/edk2(master)>git grep CPU_EXCEPTION_NUM -- *.h ]> UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h:29:#define ]> CPU_EXCEPTION_NUM 32 ]> ]> ]> https://svn.code.sf.net/p/edk2/code/trunk/edk2/UefiCpuPkg/Library/CpuExcept ]> ionHandlerLib/DxeSmmCpuException.c ]> ]> RESERVED_VECTORS_DATA mReservedVectorsData[CPU_EXCEPTION_NUM]; ]> EFI_CPU_INTERRUPT_HANDLER ]> mExternalInterruptHandlerTable[CPU_EXCEPTION_NUM]; ... ]> /** ]> Common exception handler. ]> ]> @param ExceptionType Exception type. ]> @param SystemContext Pointer to EFI_SYSTEM_CONTEXT. ]> **/ ]> VOID ]> EFIAPI ]> CommonExceptionHandler ( ]> IN EFI_EXCEPTION_TYPE ExceptionType, ]> IN EFI_SYSTEM_CONTEXT SystemContext ]> ) ]> { ]> EXCEPTION_HANDLER_CONTEXT *ExceptionHandlerContext; ]> ]> ExceptionHandlerContext = (EXCEPTION_HANDLER_CONTEXT *) (UINTN) ]> (SystemContext.SystemContextIa32); ]> ]> switch (mReservedVectors[ExceptionType].Attribute) { ]> … ]> ]> if (mExternalInterruptHandler[ExceptionType] != NULL) { ]> (mExternalInterruptHandler[ExceptionType]) (ExceptionType, ]> SystemContext); } else if (ExceptionType < CPU_EXCEPTION_NUM) { ]> // ]> // Get Spinlock to display CPU information ]> // ]> while (!AcquireSpinLockOrFail (&mDisplayMessageSpinLock)) { ]> CpuPause (); ]> } ]> // ]> // Display ExceptionType, CPU information and Image information ]> // ]> DumpCpuContent (ExceptionType, SystemContext); ]> // ]> // Release Spinlock of output message ]> // ]> ReleaseSpinLock (&mDisplayMessageSpinLock); ]> // ]> // Enter a dead loop if needn't to execute old IDT handler further ]> // ]> if (mReservedVectors[ExceptionType].Attribute != ]> EFI_VECTOR_HANDOFF_HOOK_BEFORE) { CpuDeadLoop (); ]> } ]> } ] ]-- ]============================================================================= ]-Bill Paul (510) 749-2329 | Senior Member of Technical Staff, ] [email protected] | Master of Unix-Fu - Wind River Systems ]============================================================================= ] "I put a dollar in a change machine. Nothing changed." - George Carlin ]============================================================================= ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
