From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 058172095A6B7 for ; Mon, 26 Jun 2017 17:34:41 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 600817486C; Tue, 27 Jun 2017 00:36:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 600817486C Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 600817486C Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-99.phx2.redhat.com [10.3.116.99]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1F94B7E4A7; Tue, 27 Jun 2017 00:36:08 +0000 (UTC) From: Laszlo Ersek To: "Gabriel L. Somlo" , edk2-devel@ml01.01.org Cc: liming.gao@intel.com, star.zeng@intel.com References: <20170626171354.GK29456@HEDWIG.INI.CMU.EDU> <9a43884f-ca38-c92d-2e45-5719b54cd0e8@redhat.com> Message-ID: <34ac71c1-4b40-cace-3447-20d0bb28fe3f@redhat.com> Date: Tue, 27 Jun 2017 02:36:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <9a43884f-ca38-c92d-2e45-5719b54cd0e8@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 27 Jun 2017 00:36:10 +0000 (UTC) Subject: Re: can't boot OVMF guest after commit 45cfcd8 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 00:34:41 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/26/17 21:52, Laszlo Ersek wrote: > Hi Gabriel, > > On 06/26/17 19:13, Gabriel L. Somlo wrote: >> Hi, >> >> Following commit 45cfcd8dccf84b8abbc1d6f587fedb5d2037ec79, a.k.a. >> "MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocol", >> I'm no longer able to boot a VM guest with OVMF. Using command line: >> >> bin/qemu-system-x86_64 -machine q35,accel=kvm -m 2048 -bios OVMF.fd \ >> -device ide-drive,bus=ide.2,drive=CD \ >> -drive id=CD,if=none,snapshot=on,file=Fedora-Workstation-Live-x86_64-25-1.3.iso >> >> everything hangs at the Tianocore splash screen indefinitely. >> >> Reverting the commit locally gets things to work fine once again. >> >> Sorry for the noise if this report is a dupe, otherwise please let me >> know if/what other information and test results I can provide to >> help. > > Thank you for the report and for identifying the commit -- I guess I > should have stumbled upon this myself, but other duties have kept me > from building OVMF for a while now. :/ > > Can you please add the following options to your QEMU command line, > for capturing the OVMF debug log? Maybe we'll know better where the > problem occurs this way. > > -debugcon file:debug.log -global isa-debugcon.iobase=0x402 > > In addition, > > -serial stdio > > might help you catch a register dump (written to serial) from the > default CPU exception handler in UefiCpuPkg, if an unhandled page > fault occurs, for example. Yes, it is a crash: > !!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - 00000000 !!!! > ExceptionData - 0000000000000000 > RIP - 000000007F4CFB72, CS - 0000000000000038, RFLAGS - 0000000000010282 > RAX - 8000000000000010, RCX - 8000000000000010, RDX - 0000000000000000 > RBX - 0000000000000013, RSP - 000000007F6BB670, RBP - 000000007F6BB690 > RSI - 0000000000000000, RDI - 000000007E303D98 > R8 - 8000000000000010, R9 - 0000000000000000, R10 - 0000000FFFFFFFFF > R11 - 0000000000000018, R12 - 0000000000000000, R13 - 0000000000000000 > R14 - 0000000000000000, R15 - 0000000000000000 > DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 > GS - 0000000000000030, SS - 0000000000000030 > CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 000000007F65A000 > CR4 - 0000000000000668, CR8 - 0000000000000000 > DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 > DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 > GDTR - 000000007F5ADA98 0000000000000047, LDTR - 0000000000000000 > IDTR - 000000007E897018 0000000000000FFF, TR - 0000000000000000 > FXSAVE_STATE - 000000007F6BB2D0 > !!!! Find image > /.../Build/Ovmf3264/NOOPT_GCC48/X64/MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe/DEBUG/DevicePathDxe.dll > (ImageBase=000000007F4CF000, EntryPoint=000000007F4CF27B) !!!! It happens like this: The IsaBusControllerDriverStart() function in "IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBus.c", opens two protocol interfaces BY_DRIVER, a Device Path and an ISA ACPI one. Either of these can fail, and the returns with an error in such cases, *except* when the protocol opens BY_DRIVER fail with EFI_ALREADY_STARTED. (This means that the driver has bound the controller already.) Before commit 45cfcd8dccf8, the protocol interface addresses would be returned on EFI_ALREADY_STARTED, and then IsaBusControllerDriverStart() would proceed to: - call: REPORT_STATUS_CODE_WITH_DEVICE_PATH ( EFI_PROGRESS_CODE, (EFI_IO_BUS_LPC | EFI_IOB_PC_INIT), ParentDevicePath ); which is what crashes with commit 45cfcd8dccf8 in place, since ParentDevicePath keeps its initial garbage (non-NULL) contents from the stack, on EFI_ALREADY_STARTED, - call: IsaAcpi->InterfaceInit (IsaAcpi); - do a bunch of similar stuff, regardless of whether the same driver has bound the same controller previously. It even has a comment like // // Create handle for this ISA device // // If any child device handle was created in previous call to Start() and not stopped // in previous call to Stop(), it will not be created again because the // InstallMultipleProtocolInterfaces() boot service will reject same device path. // So I guess what the driver does is intentional, but the way it requires gBS->OpenProtocol() to return a valid Interface even on error seems to conflict with the UEFI spec. And now commit 45cfcd8dccf8 makes that show. I'll follow up under [edk2] [PATCH V4] MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocol and CC you. Thanks Laszlo