Re: [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

["Gao, Liming" <liming.gao@intel.com>]

I agree to root cause this issue with GCC6. Could you help submit this issue in bugzilia? Then, we will investigate it further. 

Thanks
Liming
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Friday, December 02, 2016 2:43 AM
To: Anthony PERARD <anthony.perard@citrix.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>; Zhu, Yonghong <yonghong.zhu@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: edk2-devel@ml01.01.org
Subject: Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

On 12/01/16 16:28, Anthony PERARD wrote:
> Hi,
> 
> That might be only with the Xen part of OVMF but now that the GCC5 
> toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail 
> to boot in Xen guests.
> 
> Here is the result:
> !!!! X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID - 00000000 !!!!
> RIP  - 000000001F26AF6B, CS  - 0000000000000038, RFLAGS - 
> 0000000000010202 RAX  - 0000000000000001, RCX - 000000001F26AF51, RDX 
> - 0000000000000004 RBX  - 0000000000000000, RSP - 000000001F43C510, 
> RBP - 000000001E583D18 RSI  - 0000000000000003, RDI - 0000000000000001
> R8   - 0000000000000000, R9  - 0000000000000000, R10 - 000000001E58DB98
> R11  - 0000000000000002, R12 - 000000001E58D898, R13 - 
> 0000000000000000
> R14  - 000000001E58D8A0, R15 - 000000001F26D001
> DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
> GS   - 0000000000000030, SS  - 0000000000000030
> CR0  - 0000000080000033, CR2 - 0000000000000000, CR3 - 
> 000000001F3DB000
> CR4  - 0000000000000668, CR8 - 0000000000000000
> DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 
> 0000000000000000
> DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 
> 0000000000000400 GDTR - 000000001F3C9A98 0000000000000047, LDTR - 0000000000000000
> IDTR - 000000001EB0A018 0000000000000FFF,   TR - 0000000000000000
> FXSAVE_STATE - 000000001F43C170
> !!!! Find PE image ./Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/XenBusDxe.dll (ImageBase=000000001F266000, EntryPoint=000000001F2669D5) !!!!
> 
> Removing the gcc option -flto in only the XenBusDxe module makes OVMF 
> boot.
> 
> While trying to debug that, I've added some debug prints (in this 
> module and in XenPvBlkDxe), and the exception could change and become 
> a "page fault" instead, or even an assert failure in the PrintLib, 
> that was the ASSERT(Buffer != NULL) at I think
> MdePkg/Library/BasePrintLib/PrintLibInternal.c:366
> 
> Adding EFIAPI to internal functions in XenBusDxe makes things work 
> again.  My guest is that gcc would bypass (optimise) an exported 
> functions and call directly an internal one but without reordering the 
> arguments (EFIAPI vs nothing).
> 
> Does that make sense?

Thank you for the investigation. It is strange that only the Xen modules are 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 should *not* need EFIAPI for functions with external linkage if the calls to them 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 toolchain 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 the "-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 files 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, there is no NOOPT, and DEBUG means actually NOOPT -- if I remember correctly. Ard 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/Include/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
> 
>  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(+)
> 

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel