On 03/02/15 17:15, Ard Biesheuvel wrote: > On 2 March 2015 at 16:06, Laszlo Ersek <ler...@redhat.com> wrote: >> On 03/02/15 16:26, Gabriel L. Somlo wrote: >>> Hi, >>> >>> Somewhere between commits bbc3758ab5bc0e526994a63d739d445416ff0c07 and >>> d401a487416926594f5176cb8acf75eed4bea0f0 a bug was introduced which >>> causes a booting qemu x86_64 vm to hang with a black screen. Getting >>> OVMF to generate a debug log shows this: >>> >>> ... >>> Loading driver FAB5D4F4-83C0-4AAF-8480-442D11DF6CEA >>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7F40B240 >>> Loading driver at 0x0007ED7C000 EntryPoint=0x0007ED7C2AF VirtioScsiDxe.efi >>> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F3FA698 >>> InstallProtocolInterface: 18A031AB-B443-4D1A-A5C0-0C09261E9F71 7ED81420 >>> InstallProtocolInterface: 107A772C-D5E1-11D4-9A46-0090273FC14D 7ED81480 >>> InstallProtocolInterface: 6A7A5CFF-E8D9-4F70-BADA-75AB3025CE14 7ED814A0 >>> Loading driver CF569F50-DE44-4F54-B4D7-F4AE25CDA599 >>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7F40B040 >>> Loading driver at 0x0007ED76000 EntryPoint=0x0007ED762AF XenIoPciDxe.efi >>> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F3FA398 >>> InstallProtocolInterface: 18A031AB-B443-4D1A-A5C0-0C09261E9F71 7ED799A0 >>> InstallProtocolInterface: 107A772C-D5E1-11D4-9A46-0090273FC14D 7ED79A00 >>> InstallProtocolInterface: 6A7A5CFF-E8D9-4F70-BADA-75AB3025CE14 7ED79A20 >>> Loading driver 565EC8BA-A484-11E3-802B-B8AC6F7D65E6 >>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7F400E40 >>> Loading driver at 0x0007ED64000 EntryPoint=0x0007ED642AF XenBusDxe.efi >>> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F3FA098 >>> >>> ASSERT_EFI_ERROR (Status = Not Found) >>> ASSERT >>> /home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC49/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/AutoGen.c(262): >>> !EFI_ERROR (Status) >>> >>> >>> I was going to bisect, but bbc3758ab5bc0e526994a63d739d445416ff0c07 >>> also crashes during build, and I don't know if it's supposed to be >>> "good" or "bad" from the point of view of the bug I'm actually chasing >>> :) >>> >>> Please help (and sorry if this is already known, it just started >>> happening to me after I pulled an hour or so ago)... >> >> I found this bug literally three minutes ago. :) >> > > Whoops, blind spot! We made sure everything still works ok under Xen > on x86, but I completely forgot about the Ovmf/x86 on !Xen case. > My apologies. > >> The problem is that the xen hypercall lib initialization (the >> constructor) fails in a non-Xen guest. Library constructor failures >> trigger ASSERT_EFI_ERROR()s in autogenerated code. >> >> The right way to go about this is to call the library initialization >> routine manually in client modules (which is XenBusDxe in this >> instance), and if it fails, then exit the driver's entry point with an >> error. >> >> It's quite bad that I didn't notice this during review. If Ard wants to >> send a fix, that's good, otherwise I'll fix it up soon myself. >> > > Well, could we first align on how to approach this?
What, you want me to think before acting? :) > Calling the > constructor explicitly is fine imo, but it means I should add an empty > constructor to the ARM version as well. The ARM version is used in > other (early) places as well, such as the XenConsoleSerialPortLib, and > to be 100% correct, we should add calls to the constructor to those as > well. Or we don't bother, which is also fine by me. You are right. Please add the XenHypercallLibInit() function to the library class (OvmfPkg/Include/Library/XenHypercallLib.h). The prototype of the current XenHypercallLibIntelInit() function looks appropriate. Please implement it as "return RETURN_SUCCESS" in the ARM instance, and as XenHypercallLibIntelInit() in the Intel instance. Then all library users should indeed call this interface: - SerialPortInitialize() in "OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c", - and XenBusDxeDriverEntryPoint() in "OvmfPkg/XenBusDxe/XenBusDxe.c". For the former, you can just fail the serial port lib constructor if the hypercall lib init fails (which will be "never" in practice, because XenConsoleSerialPortLib is only used on ARM, where the hypercall library init will always succeed). For the latter, you can exit the driver's entry point as first step (with EFI_ABORTED, or even just propagating the "not found" from XenHypercallLibIntelInit()). Thanks! Laszlo ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
