Re: [edk2] [UefiCpuPkg] how did this ever work.

Subject: Re: [edk2] [UefiCpuPkg] how did this ever work.

From: "Scott Duplichan" <scott@notabs.org>

To: <edk2-devel@lists.sourceforge.net>

Date: 2014-08-09 07:25:39

Bill Paul [mailto:wpaul@windriver.com] 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:
]
]> Im still working on porting the CpuExceptionHandlerLib to clang, but I hit
]> some code I dont understand? I have mods in the assembly code but..
]> 
]> Im running in QEMU and Im 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
Developers 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,
]                 wpaul@windriver.com | Master of Unix-Fu - Wind River Systems
]=============================================================================
]   "I put a dollar in a change machine. Nothing changed." - George Carlin
]=============================================================================



------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel