On Aug 13, 2013, at 3:28 PM, Tim Lewis <tim.le...@insyde.com> wrote:
> While debugging an issue on NT32, I ran into an issue where PEIMs executing
> after permanent memory is installed continue to access temporary memory.
> After some debugging, the root cause is the
> MdePkg/Library/PeiServicesTablePointerLib, which simply tries to store the
> PEI SERVICES table pointer in a global variable. But this global variable is
> not shared by all PEIMs. So when the PEI Core updates the PEI Services table
> pointer, after permanent memory is installed, the other drivers are not
> updated. Instead they still point to the old PEI Services table pointer.
>
> As evidence of this, in NT32’s SecMain.c, there is the following code
> commented out (which is supposed to simulate the invalidated Temp RAM). If
> enabled, the code will hang at the first attempt to call a PEI Service. In
> most cases, this is one of the DEBUG() macro calls that end up calling the
> ReportStatusCode dispatch, which tries to get the HOB list.
>
> //
> // Simulate to invalid temporary memory, terminate temporary memory
> //
> //ZeroMem ((VOID*)(UINTN)TemporaryMemoryBase, CopySize);
>
>
> Obviously PeiServicestablePointerLib is designed to work when there is really
> RAM available (as with NT32 or a system with RAM from the start). But,
> because it does not use a true global storage location, it violates one of
> the key design constraints for PEI: it must be global for everyone. That is
> why the IDT was chosen on x86.
>
> My initial thought was to try to signal on Permanent Memory Installed to
> update the PEI Services pointer, since the NOTIFY function is passed the PEI
> Services table pointer from the PEI Core. Thoughts?
>
Tim,
I ended up fixing this in the EmulatorPkg with a FixedAtBuild PCD that points
to a magic memory page allocated by the Application. Since the memory space for
an application for any given OS is generally known you still have to pick and
address (or an address per OS) that would be available. I would not say it is
ideal, but it has not causes any issues yet on Linux or OS X that I know about.
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EmulatorPkg/Include/Library/EmuMagicPageLib.h
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EmulatorPkg/Library/PeiServicesTablePointerLibMagicPage/
This solution also has the side benefit of enabling DEBUG/ASSERT macros in SEC
(which is a separate module in the EmulatorPkg), and early PEI Core. It also
allows the emulator to write protect the recovery FV, since a write to a FLASH
location could be a bug on real hardware.
Due to privilege limitations in OS applications I could not come up with a
better way to solve this problem. This is a really big "chicken and egg"
problem since all the modules are not linked together they don't have anyway to
communicate via a global, and they would need to linked against OS APIs to
communicate, and the point of the emulator is to not require that.
Thanks,
Andrew Fish
PS I think this was copied from the EDK so it has been like this in NT32 for a
long time.
PPS The only other thing I could think of was to have a signal handler in the
Application that would trap on some illegal operation. So for example you could
trap on SIGILL and filter for ILL_PRVOPC to trap on privileged instructions,
and let other versions of the fault through. So the signal hander would emulate
the instruction and resume. Conceptually it is possible, but when I talked to
our debugger folks they let me know getting code like this to play well with
the debugger can get to be very complicated, and the behavior between different
debuggers could be a little different. I did not have the time to invest in
this one, and my "Magic Page" temporary work around worked better than I
thought, so I never went down this path.
> Thanks,
>
> Tim
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
