This error is caused by iPXE driver not return the correct string in EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig() function. Base on the spec requirement, if the function return success, the Results string should follow <MultiConfigAltResp>format. But the data returned by iPXE driver is not follow this rule, so the ASSERT raised. Detail can check UEFI spec 2.6 chapter 33.2.1.5 and 33.5.
Thanks, Eric -----Original Message----- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, March 29, 2016 11:21 PM To: Bi, Dandan; Dong, Eric; Michael Brown Cc: edk2-devel-01; Justen, Jordan L; Ard Biesheuvel Subject: HII incompatibility between edk2 and iPXE? Hi, recent edk2 commit 8a45f80edad4 ("MdeModulePkg: Make HII configuration settings available to OS runtime") seems to trigger an issue between edk2 and iPXE. (Note: I'm not saying that 8a45f80edad4 causes the issue, just that it exposes it.) Namely, when you boot a brand new QEMU VM with OVMF (and iPXE presented in the NIC's option ROM), then an HII ASSERT() fails. I've come across the issue report in <https://www.redhat.com/archives/vfio-users/2016-March/msg00153.html>, reproduced it, and collected some data to assist with the analysis. The failed assertion is: > ASSERT MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c(1256): > TmpRequest != ((void *) 0) Here's the edk2 stack dump: > #0 0x000000007fda4070 in CpuDeadLoop () > at MdePkg/Library/BaseLib/CpuDeadLoop.c:37 > #1 0x000000007fda30d5 in DebugAssert ( > FileName=0x7fda47d8 > "MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c", LineNumber=1256, > Description=0x7fda4a20 "TmpRequest != ((void *) 0)") > at OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153 > #2 0x000000007fd8166f in GetElementsFromRequest (ConfigRequest=0x7eeee898) > at MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c:1256 > #3 0x000000007fd8629c in HiiConfigRoutingExportConfig (This=0x7fda9190, > Results=0x7ff5e9f0) > at MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c:4242 > #4 0x000000007fd90e02 in HiiGetConfigurationSetting (This=0x7fda9138) > at MdeModulePkg/Universal/HiiDatabaseDxe/Database.c:2815 > #5 0x000000007fd7c7ae in OnReadyToBoot (Event=0x7f645098, Context=0x0) > at MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseEntry.c:147 > #6 0x000000007ff7c785 in CoreDispatchEventNotifies (Priority=8) > at MdeModulePkg/Core/Dxe/Event/Event.c:200 > #7 0x000000007ff7bdda in CoreRestoreTpl (NewTpl=4) > at MdeModulePkg/Core/Dxe/Event/Tpl.c:131 > #8 0x000000007ff6a030 in CoreReleaseLock (Lock=0x7ff9ac70) > at MdeModulePkg/Core/Dxe/Library/Library.c:102 > #9 0x000000007ff7c560 in CoreReleaseEventLock () > at MdeModulePkg/Core/Dxe/Event/Event.c:119 > #10 0x000000007ff7c9cc in CoreNotifySignalList (EventGroup=0x7eeed8d0) > at MdeModulePkg/Core/Dxe/Event/Event.c:276 > #11 0x000000007ff7ce60 in CoreSignalEvent (UserEvent=0x7eeed898) > at MdeModulePkg/Core/Dxe/Event/Event.c:564 > #12 0x000000007ebe610c in EfiSignalEventReadyToBoot () > at MdePkg/Library/UefiLib/UefiNotTiano.c:235 > #13 0x000000007ebde969 in BdsLibBootViaBootOption (Option=0x7eeecd18, > DevicePath=0x7eeeb958, > ExitDataSize=0x7ff5ed38, ExitData=0x7ff5ed30) > at IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c:2279 > #14 0x000000007ebaf0a3 in BdsBootDeviceSelect () > at IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:286 > #15 0x000000007ebafc1a in BdsEntry (This=0x7ebfbec0) > at IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:659 > #16 0x000000007ff6096a in DxeMain (HobStart=0x7fd14018) > at MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:517 > #17 0x000000007ff5f71d in ProcessModuleEntryPointList (HobStart=0x7bfde000) > at > Build/OvmfX64/DEBUG_GCC48/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/AutoGen.c:423 > #18 0x000000007ff5f26d in _ModuleEntryPoint (HobStart=0x7bfde000) > at MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:54 > #19 0x0000000000000000 in ?? () According to my (superficial) tracing, the following happens (see stack frame #3 above): the HiiConfigRoutingExportConfig() function in "MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c" repeatedly calls EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig(), on drivers / handles that export that protocol. Subsequently, each serialized configuration (in the output parameter called "AccessResults") is passed to GetElementsFromRequest(), in the same C source file. The GetElementsFromRequest() function asserts that the "PATH=" substring is present in the AccessResults string. This assertion breaks down when iPXE returns the following result string to HiiConfigRoutingExportConfig(): > gateway=&ip=&netmask=&dns=&dnssl=&domain=&filename=&next-server=&root-path=&keep-san=&skip-san-boot=&hostname=&user-class=&password=&username=&dhcp-server=&priority=&scriptlet= Note that my only reason for pointing at iPXE is this result string precisely. Namely, I grepped the edk2 source for various tokens in the above (like "scriptlet" and "skip-san-boot"), and came up empty. Then I grepped iPXE for the same tokens, and I found them (in "src/usr/autoboot.c"). I think the function that actually formats the response string in iPXE is efi_snp_hii_extract_config() [src/interface/efi/efi_snp_hii.c]. I don't know which component this error should be fixed in. However, since (a) OVMF doesn't have much use for the (optional) feature introduced in edk2 commit 8a45f80edad4, and (b) the problem doesn't seem to be specific to OVMF, I intend to post patches for both OvmfPkg and ArmVirtPkg that disable PcdHiiOsRuntimeSupport. That will save some runtime memory for the OS (see the discussion rooted at <http://thread.gmane.org/gmane.comp.bios.edk2.devel/7626/focus=7642>), and also prevent this edk2 <-> iPXE conflict from tripping up most OVMF users. Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
