On 11/30/15 22:59, Andrew Fish wrote:
>
>> On Nov 30, 2015, at 12:27 PM, Laszlo Ersek <ler...@redhat.com> 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
Maybe there's something about the DXE core image file that differs from the
PEIM images, and rubs this code the wrong way? I have no idea.
Perhaps if Alain digs down the LoadAndRelocatePeCoffImage() function, it can be
unearthed where the EFI_INVALID_PARAMETER status comes from.
The build rules from the end of the OvmfPkg/OvmfPkgX64.fdf file could be
relevant:
[Rule.Common.PEIM]
FILE PEIM = $(NAMED_GUID) {
PEI_DEPEX PEI_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
PE32 PE32 Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
UI STRING="$(MODULE_NAME)" Optional
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
}
[Rule.Common.DXE_CORE]
FILE DXE_CORE = $(NAMED_GUID) {
PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
UI STRING="$(MODULE_NAME)" Optional
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
}
Thanks
Laszlo
>
> 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
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
