On Tue, Dec 3, 2013 at 1:56 PM, Laszlo Ersek <ler...@redhat.com> wrote: > it's as if different parts of the code thought differently about > PcdDxeIplSwitchToLongMode. > > Interpretation #1: > - PcdDxeIplSwitchToLongMode means that we have to *switch* from 32-bit > PEI to 64-bit DXE. Emphasis on "switch", that is, "PEI and DXE have > different bitness". > > Interpretation #2: > - PcdDxeIplSwitchToLongMode means that DXE is 64-bit, independently of > PEI bitness.
Clearly the name indicates that DxeIpl needs to switch into long-mode. It seems there are two cases where this can be false, yet DXE can be 64-bit: * 64-bit only OVMF * 64-bit EmulatorPkg Is a new PCD needed, or can PEI code use: Has64BitDxe = (sizeof(UINTN) == sizeof(UINT64)) || (FeaturePcdGet (PcdDxeIplSwitchToLongMode); I don't think 64-bit PEI with a 32-bit DXE is supported. -Jordan > PcdDxeIplSwitchToLongMode > PEI DXE Interp#1 Interp#2 result > 32 32 0 0 OK > 32 64 1 1 OK > 64 64 0 1 oops > > I checked the documentation in MdeModulePkg/MdeModulePkg.dec, and I have > no clue which interpretation it follows. > > The picture is further complicated by "PcdDxeIplBuildPageTables" (added > in SVN r12016. It seems to allow one to say (by setting it to FALSE), > "64-bit PEI, 64-bit DXE, but please don't rebuild page tables". > > Now, in OVMF, the 32/32 platform DSC file sets PcdDxeIplSwitchToLongMode > to FALSE. No difference between interp#1 and interp#2. > > The 32/64 DSC file sets it to TRUE. Detto. > > The 64/64 DSC file it to FALSE again, clearly following interp#1 -- "no > switching needed". > > Maybe, we should set this PCD to TRUE (ie. follow Interp#2), and turn > off rebuilding the page tables by setting the newer > PcdDxeIplBuildPageTables to FALSE. I have no clue. (We don't use this > second PCD in OVMF, only EmulatorPkg and Nt32Pkg do -- they both set it > to FALSE.) > > If OVMF interprets PcdDxeIplSwitchToLongMode differently (==interp#1) > from some other parts of the code (interp#2), well that has not been > causing problems until now, apparently. > > But now I'm looking at the S3 suspend/resume code, and it is full of > comments that apparently *equate* > > PcdDxeIplSwitchToLongMode==FALSE > > with > > DXE is 32-bit > > Which corresponds to Interp#2. > I'm asking because I'm now reaching the assembly code in > "MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S" that > would jump to the (real mode) OSPM waking vector, and it reboots the > machine. I think that maybe the wrong routine is invoked, due to > confusion around PcdDxeIplSwitchToLongMode. > (The reboot happens when LRET pops RIP and CS from the stack. Apparently > the idea behind this exercise is to stay/continue in the same ASM file, > but change the CS. It doesn't work.) > > Thanks! > Laszlo > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
