From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from esa5.hc3370-68.iphmx.com (esa5.hc3370-68.iphmx.com [216.71.155.168]) by mx.groups.io with SMTP id smtpd.web12.989.1587386324011735004 for ; Mon, 20 Apr 2020 05:38:44 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@citrix.com header.s=securemail header.b=KZA8H5s5; spf=pass (domain: citrix.com, ip: 216.71.155.168, mailfrom: anthony.perard@citrix.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1587386323; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=KVcRdMbo1GoWmiA14XZrG7VR6aVTccS6hDXcHOBdm2I=; b=KZA8H5s5tCdk34on9TJxP9n4jwHOhRGAX1B3XKBhz4Sbeood8hWlUjZ6 5a/P+QRcHaN+F7No4l2Yegjl73fKpNIcoBBG0gvmq5WiNKN6Tneo45mYS 5X1Xu/OP/R5wJiE5cZDbWLCXqL1rqMCcHWJ+VP1GeWshiJw/ZgG8MtFxu A=; Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=anthony.perard@citrix.com; spf=Pass smtp.mailfrom=anthony.perard@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender authenticity information available from domain of anthony.perard@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="anthony.perard@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of anthony.perard@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="anthony.perard@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ip4:168.245.78.127 ~all" Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: DhrIBkl3QwVWOM9fzm5HKkdpEA7zuaGqFAJYkRXHDHSa+nOhvTYew6DBmb6MV18QZukSnoGn0A D/dv4Mo2KnDFNjhb1inmCHHPEHauR4EQq4HuMVk9PTmHdb9THXEYMFGdDzPosgcvG0lkm8NewE ney8MgbLcHNXBWF43pkKansSsRlTgweJJA3TeLqDdjcuMYR/xW8ocqmtJIi9Qvi/kqKvyvgIu4 VL4erNAKOOWWQe9c6wKEV+UmD2uDJfkoPVD76r0/pKyzHT6KT1v8Tp3TuRYxlUN/ZLnv5ir673 Qz0= X-SBRS: 2.7 X-MesageID: 16248676 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="16248676" Date: Mon, 20 Apr 2020 13:38:40 +0100 From: "Anthony PERARD" To: Laszlo Ersek CC: Rebecca Cran , , Julien Grall , Ard Biesheuvel Subject: Re: OvmfPkg XenPkg: X64 DEBUG GCC5 -DDEBUG_ON_SERIAL_PORT=TRUE build is broken Message-ID: <20200420123840.GO4088@perard.uk.xensource.com> References: MIME-Version: 1.0 In-Reply-To: Return-Path: anthony.perard@citrix.com Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline On Wed, Apr 15, 2020 at 04:04:35PM +0200, Laszlo Ersek wrote: > On 04/14/20 20:01, Rebecca Cran wrote: > > I was trying to build OvmfPkg/XenPkg -a X64 -t GCC5 -b DEBUG > > -DDEBUG_ON_SERIAL_PORT=TRUE, but the build fails. Both plain DEBUG and > > RELEASE builds without trying to put the debug output on the serial > > port work. > > > > > > [bcran@smic ~/src/tmp/edk2]$ build -p OvmfPkg/OvmfXen.dsc -a X64 -t > > GCC5 -b DEBUG -DDEBUG_ON_SERIAL_PORT=TRUE > > Build environment: FreeBSD-13.0-CURRENT-amd64-64bit-ELF > > Build start time: 11:59:24, Apr.14 2020 > > > > WORKSPACE = /home/bcran/src/tmp/edk2 > > EDK_TOOLS_PATH = /home/bcran/src/tmp/edk2/BaseTools > > CONF_PATH = /home/bcran/src/tmp/edk2/Conf > > PYTHON_COMMAND = /usr/local/bin/python3 > > > > > > Processing meta-data . > > Architecture(s) = X64 > > Build target = DEBUG > > Toolchain = GCC5 > > > > Active Platform = /home/bcran/src/tmp/edk2/OvmfPkg/OvmfXen.dsc > > . > > > > build.py... > > /home/bcran/src/tmp/edk2/OvmfPkg/OvmfXen.dsc(...): error F002: Library > > [/home/bcran/src/tmp/edk2/MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf] > > with constructors has a cycle > > consumed by > > /home/bcran/src/tmp/edk2/MdePkg/Library/UefiLib/UefiLib.inf > > consumed by > > /home/bcran/src/tmp/edk2/MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLibDevicePathProtocol.inf > > From commit 05480e2fd4ff ("OvmfPkg/PlatformBootManagerLib: Use a Xen > console for ConOut/ConIn", 2019-08-21), we have: > > > diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc > > index 54ac910d8eed..e719a168f81e 100644 > > --- a/OvmfPkg/OvmfXen.dsc > > +++ b/OvmfPkg/OvmfXen.dsc > > @@ -586,6 +586,10 @@ [Components] > > OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf > > OvmfPkg/XenBusDxe/XenBusDxe.inf > > OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf > > + MdeModulePkg/Universal/SerialDxe/SerialDxe.inf { > > + > > + SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf > > + } > > MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf > > MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf > > MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf > > If you run the "build" command with the "-v" option added, the last part > (just preceding the error message above) is: > > > Library instances of module [MdeModulePkg/Universal/SerialDxe/SerialDxe.inf] [X64]: > > UefiDriverEntryPoint : MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf > > UefiBootServicesTableLib : MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf > > DebugLib : MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf > > PcdLib : MdePkg/Library/DxePcdLib/DxePcdLib.inf > > SerialPortLib : OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf > > BaseLib : MdePkg/Library/BaseLib/BaseLib.inf > > XenHypercallLib : OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf > > HobLib : MdePkg/Library/DxeHobLib/DxeHobLib.inf > > BaseMemoryLib : MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf > > UefiLib : MdePkg/Library/UefiLib/UefiLib.inf > > PrintLib : MdePkg/Library/BasePrintLib/BasePrintLib.inf > > MemoryAllocationLib : MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf > > DevicePathLib : MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLibDevicePathProtocol.inf > > UefiRuntimeServicesTableLib : MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf > > DebugPrintErrorLevelLib : MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf > > The dependency loop is formed by: > > DebugLib : BaseDebugLibSerialPort -> > SerialPortLib : XenConsoleSerialPortLib -> > XenHypercallLib : XenHypercallLib -> > DebugLib > > where all the library instances BaseDebugLibSerialPort, > XenConsoleSerialPortLib, XenHypercallLib have constructors. > > Note that XenConsoleSerialPortLib *itself* is careful to avoid a > DebugLib dependency; from "XenConsoleSerialPortLib.c": > > > // > > // We can't use DebugLib due to a constructor dependency cycle between DebugLib > > // and ourselves. > > // > > #define ASSERT(Expression) \ > > do { \ > > if (!(Expression)) { \ > > CpuDeadLoop (); \ > > } \ > > } while (FALSE) > > However, XenConsoleSerialPortLib still inherits a DebugLib dependency > through XenHypercallLib -- but only on IA32/X64, not on ARM/AARCH64! See > "XenHypercallLib.inf": > > > [LibraryClasses.IA32, LibraryClasses.X64] > > BaseLib > > HobLib > > DebugLib > > There is no issue without specifying DEBUG_ON_SERIAL_PORT, because > OvmfXen resolves DebugLib to PlatformDebugLibIoPort then, which does not > depend on SerialPortLib (thus the cycle is severed). > > > Now, I think there may not be a simple solution for this, because, as > the message on commit 05480e2fd4ff says, "On a Xen PVH guest, none of > the existing serial or console interface works". > > So even if we eliminated the constructor cycle for this module -- i.e., > SerialDxe -- somehow [1], the larger DEBUG_ON_SERIAL_PORT feature might > not be feasible for *some* module types in OvmfXen. Because, > XenConsoleSerialPortLib ultimately depends on hypercalls, and I'm unsure > if those could be used as early as in SEC / PEI. > > [1] For breaking up just this one constructor cycle, I guess we could > remove the DebugLib dependency from XenHypercallLib even on > IA32/X64. > > In other words, I'm not sure if you could send any DEBUG messages *at > all* to the Xen serial port as early as in SEC or PEI. Meaning that even > if DEBUG_ON_SERIAL_PORT didn't break the build, it still wouldn't > (comprehensively) do what its name says. > > I figure you attempted the DEBUG_ON_SERIAL_PORT build because without it > you get no debug output at all (due to the default > PlatformDebugLibIoPort resolution, which produces no logs on Xen). > > For a start, I would recommend removing DEBUG_ON_SERIAL_PORT altogether > from OvmfXen (to decrease confusion and to eliminate the build > breakage), and then filing a feature request in the TianoCore bugzilla > for "some" kind of debug logging in OvmfXen, if the latter is possible. Thanks Laszlo for the investigation. I usually use DebugLib to debug OVMF under Xen, I just need to enable the debug port of QEMU. And for when QEMU isn't available (when running Xen PVH guest), I have a local patch that I haven't send upstream yet. It's a hacked version of PlatformDebugLibIoPort which sends logs to Xen's debug port, and doesn't check if the port is open. I'll prepare a patch to remove DEBUG_ON_SERIAL_PORT support from OvmfXen and send my other patch. Thanks, -- Anthony PERARD