From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 B314581F48 for ; Thu, 1 Dec 2016 20:36:57 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP; 01 Dec 2016 20:36:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,284,1477983600"; d="scan'208";a="1093506317" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga002.fm.intel.com with ESMTP; 01 Dec 2016 20:36:57 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 1 Dec 2016 20:36:56 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.239]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.116]) with mapi id 14.03.0248.002; Fri, 2 Dec 2016 12:36:53 +0800 From: "Gao, Liming" To: Laszlo Ersek , Anthony PERARD , "Justen, Jordan L" , "Zhu, Yonghong" , Ard Biesheuvel CC: "edk2-devel@ml01.01.org" Thread-Topic: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5 Thread-Index: AQHSS+hUd43xePIuTEKPfGksBV3cbaDy56oAgAEVCdA= Date: Fri, 2 Dec 2016 04:36:52 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14B4BC4BE@shsmsx102.ccr.corp.intel.com> References: <20161201152819.8341-1-anthony.perard@citrix.com> <53c67cb5-e947-8979-7738-288cc83f374b@redhat.com> In-Reply-To: <53c67cb5-e947-8979-7738-288cc83f374b@redhat.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 04:36:57 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree to root cause this issue with GCC6. Could you help submit this issu= e in bugzilia? Then, we will investigate it further.=20 Thanks Liming -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Lasz= lo Ersek Sent: Friday, December 02, 2016 2:43 AM To: Anthony PERARD ; Justen, Jordan L ; Gao, Liming ; Zhu, Yonghong ; Ard Biesheuvel Cc: edk2-devel@ml01.01.org Subject: Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compile= d with GCC5 On 12/01/16 16:28, Anthony PERARD wrote: > Hi, >=20 > That might be only with the Xen part of OVMF but now that the GCC5=20 > toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail=20 > to boot in Xen guests. >=20 > Here is the result: > !!!! X64 Exception Type - 06(#UD - Invalid Opcode) CPU Apic ID - 0000000= 0 !!!! > RIP - 000000001F26AF6B, CS - 0000000000000038, RFLAGS -=20 > 0000000000010202 RAX - 0000000000000001, RCX - 000000001F26AF51, RDX=20 > - 0000000000000004 RBX - 0000000000000000, RSP - 000000001F43C510,=20 > RBP - 000000001E583D18 RSI - 0000000000000003, RDI - 0000000000000001 > R8 - 0000000000000000, R9 - 0000000000000000, R10 - 000000001E58DB98 > R11 - 0000000000000002, R12 - 000000001E58D898, R13 -=20 > 0000000000000000 > R14 - 000000001E58D8A0, R15 - 000000001F26D001 > DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 > GS - 0000000000000030, SS - 0000000000000030 > CR0 - 0000000080000033, CR2 - 0000000000000000, CR3 -=20 > 000000001F3DB000 > CR4 - 0000000000000668, CR8 - 0000000000000000 > DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 -=20 > 0000000000000000 > DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 -=20 > 0000000000000400 GDTR - 000000001F3C9A98 0000000000000047, LDTR - 0000000= 000000000 > IDTR - 000000001EB0A018 0000000000000FFF, TR - 0000000000000000 > FXSAVE_STATE - 000000001F43C170 > !!!! Find PE image ./Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBu= sDxe/DEBUG/XenBusDxe.dll (ImageBase=3D000000001F266000, EntryPoint=3D000000= 001F2669D5) !!!! >=20 > Removing the gcc option -flto in only the XenBusDxe module makes OVMF=20 > boot. >=20 > While trying to debug that, I've added some debug prints (in this=20 > module and in XenPvBlkDxe), and the exception could change and become=20 > a "page fault" instead, or even an assert failure in the PrintLib,=20 > that was the ASSERT(Buffer !=3D NULL) at I think > MdePkg/Library/BasePrintLib/PrintLibInternal.c:366 >=20 > Adding EFIAPI to internal functions in XenBusDxe makes things work=20 > again. My guest is that gcc would bypass (optimise) an exported=20 > functions and call directly an internal one but without reordering the=20 > arguments (EFIAPI vs nothing). >=20 > Does that make sense? Thank you for the investigation. It is strange that only the Xen modules ar= e affected, I'm unsure what that's the case. Either way, it seems to be a gcc-6 bug, or an edk2 toolchain bug. You shoul= d *not* need EFIAPI for functions with external linkage if the calls to the= m straddle only files in the same module. I'm suspecting gcc-6 (we've received no such reports with gcc-5). Maybe we need a GCC6 too= lchain as well, for turning off some new features in gcc-6? Jordan, Liming, Yonghong, Ard -- any ideas? Anthony: while we all figure this out, please consider building OVMF with t= he "-b NOOPT" switch. Support for the NOOPT build target has recently been = added to the GCC Ia32/X64 toolchains in BaseTools, and to the OVMF DSC file= s as well. The build targets correspond to: RELEASE -- compiler optimization enabled; DEBUG, ASSERT, and similar DebugLib features compiled out DEBUG -- compiler optimization enabled; DebugLib features preserved NOOPT -- compiler optimization disabled; DebugLib features preserved (Note that for ArmVirtPkg and the GCC AARCH64 toolchains in BaseTools, ther= e is no NOOPT, and DEBUG means actually NOOPT -- if I remember correctly. A= rd will correct me if I'm wrong :)) If "-b NOOPT" works for you, I'd prefer that as a temporary solution (until= the root cause is found and addressed) to the XenBusDxe patches. Hrpmf, wait a second, I do see something interesting: in this series you *are* modifying APIs declared in a library class header (namely "OvmfPkg/In= clude/Library/XenHypercallLib.h"). Such functions (public libraries) *are* required to specify EFIAPI. What happens if you apply patch #1 only? Thanks! Laszlo > Anthony PERARD (4): > OvmfPkg/XenHypercallLib: Add EFIAPI > OvmfPkg/XenBusDxe: Add EFIAPI to XenEventChannelNotify > OvmfPkg/XenBusDxe: Add EFIAPI to XenStore functions > OvmfPkg/XenBusDxe: Add EFIAPI to XenGrantTable{Grant,End}Access >=20 > OvmfPkg/Include/Library/XenHypercallLib.h | 3 +++ > OvmfPkg/Library/XenHypercallLib/XenHypercall.c | 3 +++ > OvmfPkg/XenBusDxe/EventChannel.c | 1 + > OvmfPkg/XenBusDxe/EventChannel.h | 1 + > OvmfPkg/XenBusDxe/GrantTable.c | 2 ++ > OvmfPkg/XenBusDxe/XenStore.c | 13 +++++++++++++ > OvmfPkg/XenBusDxe/XenStore.h | 10 ++++++++++ > 7 files changed, 33 insertions(+) >=20 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel