> On Nov 30, 2015, at 12:27 PM, Laszlo Ersek <[email protected]> wrote: > > On 11/30/15 20:17, Alain Kalker wrote: >> Booting a debug build of OVMF on QEMU, with PcdShadowPeimOnS3Boot and >> PcdShadowPeimOnBoot set to FALSE, i'm hitting the following assertion: >> >> --[last lines of debug output]-- >> DXE IPL Entry >> >> ASSERT_EFI_ERROR (Status = Invalid Parameter) >> ASSERT /home/miki/vcs/git/edk2/MdeModulePkg/Core/Pei/Image/Image.c(603): ! >> EFI_ERROR (Status) >> --[end]-- >> >> This is on Arch Linux (x86_64), package versions: qemu 2.4.1-1, gdb >> 7.10-4.1 . >> >> To disable shadowing, I made the following change: >> >> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc >> index 44b9c79..31f73bc 100644 >> --- a/OvmfPkg/OvmfPkgX64.dsc >> +++ b/OvmfPkg/OvmfPkgX64.dsc >> @@ -340,6 +340,11 @@ >> gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2 >> !endif >> >> +!if $(TARGET) == DEBUG >> + gEfiMdeModulePkgTokenSpaceGuid.PcdShadowPeimOnS3Boot|FALSE >> + gEfiMdeModulePkgTokenSpaceGuid.PcdShadowPeimOnBoot|FALSE >> +!endif >> + >> !ifndef $(USE_OLD_SHELL) >> gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, >> 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, >> 0xB4, 0xD1 } >> !endif > > "Doctor, if I press here, it hurts". > "Well, don't press there." > > Why are you doing this in the first place? > > The documentation of "PcdShadowPeimOnBoot" goes like > [MdeModulePkg/MdeModulePkg.dec]: > >> ## Indicates if to shadow PEIM and PeiCore after memory is ready.<BR><BR> >> # This PCD is used on other boot path except for S3 boot. >> # TRUE - Shadow PEIM and PeiCore after memory is ready.<BR> >> # FALSE - Not shadow PEIM after memory is ready.<BR> >> # @Prompt Shadow Peim and PeiCore on boot >> gEfiMdeModulePkgTokenSpaceGuid.PcdShadowPeimOnBoot|TRUE|BOOLEAN|0x30001029 > > If I understand correctly, if you flip this switch to false, then the PEI > core, any already loaded PEIMs, and the temporary PEI heap and stack will not > be migrated to permanent PEI RAM, once permanent PEI RAM is installed. That > is a completely untested path in OVMF (in fact this is the first time I ever > hear of this PCD) -- why are you doing this? > > Such a change could be extremely intrusive, and (right now) I don't see any > good reason to attempt to support it. > > Anyway, the assert you seem to be hitting is in the PeiLoadImageLoadImage() > function: > > 592 // > 593 // If memory is installed, perform the shadow operations > 594 // > 595 Status = LoadAndRelocatePeCoffImage ( > 596 FileHandle, > 597 Pe32Data, > 598 &ImageAddress, > 599 &ImageSize, > 600 &ImageEntryPoint > 601 ); > 602 > 603 ASSERT_EFI_ERROR (Status); > > I also found a comment like this, in > "MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c" (note the dependency on the > PCD): > > 1143 // > 1144 // If memory is availble we shadow images by default for > performance reasons. > 1145 // We call the entry point a 2nd time so the module > knows it's shadowed. > 1146 // > 1147 //PERF_START (PeiServices, L"PEIM", PeimFileHandle, 0); > 1148 if ((Private->HobList.HandoffInformationTable->BootMode > != BOOT_ON_S3_RESUME) && !PcdGetBool (PcdShadowPeimOnBoot)) { > 1149 // > 1150 // Load PEIM into Memory for Register for shadow PEIM. > 1151 // > 1152 Status = PeiLoadImage ( > 1153 PeiServices, > 1154 PeimFileHandle, > 1155 PEIM_STATE_REGISITER_FOR_SHADOW, > 1156 &EntryPoint, > 1157 &AuthenticationState > 1158 ); > > So, my take is that you might have stumbled upon a by-now untested, > bit-rotted code path in edk2. > > On physical platforms the PEI phase is launched from flash, which is likely > slow, so as soon as DRAM is discovered, it is -- in practice -- *always* > relocated there. Which allowed the code path (enabled by the opposite PCD > setting) to bit-rot. > > I think this issue is not directly related to OVMF. >
The strange thing about this is the failure is loading the DXE Core from the DXE IPL, so all of PEI has already run and been dispatched? #2 0x0000000000822f0e in PeiLoadImageLoadImage at /home/miki/vcs/git/edk2/MdeModulePkg/Core/Pei/Image/Image.c:603 #3 0x0000000000823326 in PeiLoadImageLoadImageWrapper at /home/miki/vcs/git/edk2/MdeModulePkg/Core/Pei/Image/Image.c:722 #4 0x0000000007fc5d41 in DxeLoadCore at /home/miki/vcs/git/edk2/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c:325 #5 0x00000000008218c0 in PeiCore at /home/miki/vcs/git/edk2/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c:459 #6 0x0000000000820d43 in PeiCore at /home/miki/vcs/git/edk2/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c:271 Thanks, Andrew Fish > Thanks > Laszlo > >> For building the OVMF image, I used the following commands: >> >> $ make -C BaseTools >> $ . edksetup.sh BaseTools >> $ build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -b DEBUG -t GCC49 -n 8 >> >> To get debug output from QEMU, I used the following command: >> >> $ qemu-system-x86_64 -monitor none -serial none -chardev >> stdio,id=biosdebug -device isa-debugcon,iobase=0x402,chardev=biosdebug - >> bios Build/OvmfX64/DEBUG_GCC49/FV/OVMF.fd >> >> Using GDB (with a custom Python script to load symbols), I got a fill >> backtrace. >> I will try and post the full output from QEMU boot as well as the >> backtrace as replies to this message because many mail archives strip >> attachments. >> >> Kind regards, >> >> Alain >> >> _______________________________________________ >> edk2-devel mailing list >> [email protected] >> https://lists.01.org/mailman/listinfo/edk2-devel >> > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
