[Xen-devel] [ovmf baseline-only test] 75153: tolerable FAIL

[Platform Team regression test user <citrix-osstest@xxxxxxxxxxxxxx>]

This run is configured for baseline tests only.

flight 75153 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75153/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install     fail like 75149
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install      fail like 75149

version targeted for testing:
 ovmf                 1e57188216b1bf8de3473a0e03e422815f8f53d6
baseline version:
 ovmf                 a77e5bcac54d2e2437d7deaec9af5362c9220037

Last test of basis    75149  2018-08-31 12:57:13 Z    1 days
Testing same since    75153  2018-09-01 03:52:02 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Carsey, Jaben <jaben.carsey@xxxxxxxxx>
  Jaben Carsey <jaben.carsey@xxxxxxxxx>
  Ruiyu Ni <ruiyu.ni@xxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    


------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
    http://osstest.xensource.com/osstest/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.

------------------------------------------------------------
commit 1e57188216b1bf8de3473a0e03e422815f8f53d6
Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
Date:   Mon Aug 27 13:22:21 2018 +0800

    EmulatorPkg: IoThunk->Close() is called too early, may causing hang
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1121
    
    To produce a EFI_BLOCK_IO_PROTOCOL instance in Emulator platform,
    EmulatorPkg defines the EMU_IO_THUNK_PROTOCOL. OS dependent layer
    needs to produce this protocol implementation and a generic OS
    independent layer consumes this protocol to produce
    EFI_BLOCK_IO_PROTOCOL.
    
    EMU_IO_THUNK_PROTOCOL can also be used to abstract the OS dependent
    IO operation for other UEFI protocols, e.g.: GOP, SimpleFileSystem
    and etc.
    
    It contains two interfaces Open() and Close(). Open() creates the
    specific IO instances, e.g. for Block IO access, File System access,
    Screen access, etc. Close() destroys the specific IO instances.
    
    Later on the Emulator generic module (e.g.: EmuBlockIoDxe) calls
    Open() to create the IO instance in DriverBindingStart() and calls
    Close() in DriverBindingStop().
    But today's implementation of DriverBindingStop() contains a bug
    that it calls Close() before uninstalling the EFI_BLOCK_IO_PROTOCOL.
    
    It's a mistake in code. Take EFI_BLOCK_IO for example,
    the uninstallation may cause the upper layer driver that consumes
    EFI_BLOCK_IO call BlockIo.Reset(), which consequently calls
    EmuBlockIo.Reset(). But the EmuBlockIo instance is already destroyed
    by Close() that happens before uninstallation.
    
    So a proper implementation is to call Close() after uninstallation
    succeeds.
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1121
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Cc: Andrew Fish <afish@xxxxxxxxx>
    Reviewed-by: Hao Wu <hao.a.wu@xxxxxxxxx>

commit e01238946cbd16f2dfccd7ec86aebe20d7408586
Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
Date:   Thu Aug 30 09:53:49 2018 +0800

    EmulatorPkg: Use MdeModulePkg/Bds module
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1120
    
    Logo is enabled by adding a separate core driver LogoDxe.
    UiApp and BootManagerMenuApp are added to provide two UIs.
    
    LoadFileOnFv2 is added to auto-install LoadFile protocol for
    applications in FV so the boot options for applications can be
    auto-created from LoadFile.
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Reviewed-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Cc: Andrew Fish <afish@xxxxxxxxx>

commit 0195dd509f80b1ff49739bbf1df39434a6a7540e
Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
Date:   Fri Aug 24 16:48:04 2018 +0800

    EmulatorPkg/Win: Add VS2017 project file
    
    Developer can build the Win Host in VS2017 and launch to debug it.
    Platform 'x64' is to build 64bit EmulatorWin.
    Platform 'Win32' is to build 32bit EmulatorWin.
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Reviewed-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Cc: Andrew Fish <afish@xxxxxxxxx>

commit 54ee6176eda4f6ae1d27d53c00818e350db93f97
Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
Date:   Fri Aug 24 13:20:32 2018 +0800

    EmulatorPkg/AutoScanPei: Report the correct CPU address size
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1119
    
    Today's implementation reports CPU address size as 36 through CPU
    HOB. But when WinHost is running at 64bit, the system memory might
    be allocated above 2^36.
    
    It causes system asserts when DxeCore code tries to find the
    corresponding GCD entry for a given valid address.
    
    The patch uses 57 as the CPU address size which is maximum linear
    address size when 5-level paging is enabled in host OS.
    
    Using 64 seems more proper and a one-time change even 6-level
    paging might be invented. But it causes CoreInitializeGcdServices()
    assertion on following code:
      Entry->EndAddress = LShiftU64 (1, SizeOfMemorySpace) - 1;
    Because LShiftU64 expects SizeOfMemorySpace < 64.
    
    So to be practical, I didn't report 64 and change
    CoreInitializeGcdServices().
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Reviewed-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Cc: Andrew Fish <afish@xxxxxxxxx>

commit f89c018f3dec056e28d38686ba0778597227949e
Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
Date:   Fri Aug 24 13:16:57 2018 +0800

    EmulatorPkg/Win: Enable 64bit (SEC,PEI,DXE all run at 64bit)
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Reviewed-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Cc: Andrew Fish <afish@xxxxxxxxx>

commit e3c96c391c5e76274a0b4e4d052f5062187f00d3
Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
Date:   Fri Aug 24 11:47:25 2018 +0800

    EmulatorPkg/Win: ReadKeyStrokeEx() always returns correct KeyState
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1118
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Reviewed-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Cc: Andrew Fish <afish@xxxxxxxxx>

commit d773459e2f0b039b4630d3f78638cd40560792b4
Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
Date:   Fri Aug 24 11:45:37 2018 +0800

    EmulatorPkg/Win: Use FrameBufferBltLib for BLT operation
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Reviewed-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Cc: Andrew Fish <afish@xxxxxxxxx>

commit ce8c1d92f5f0c90e1914c61d7f747bf332874ce3
Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
Date:   Fri Aug 24 11:22:57 2018 +0800

    EmulatorPkg/EmuGopDxe: Clear screen to black in GOP.SetMode
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1118
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Reviewed-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Cc: Andrew Fish <afish@xxxxxxxxx>

commit 158b558711f5fec395b88dd64fc0d134648620d6
Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
Date:   Fri Aug 24 11:22:05 2018 +0800

    EmulatorPkg/EmuGopDxe: Fix TxtInEx.SetState SCT conformance failure
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1118
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Reviewed-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Cc: Andrew Fish <afish@xxxxxxxxx>

commit 209d095968c4c87418e547261f62966bce34b443
Author: Carsey, Jaben <jaben.carsey@xxxxxxxxx>
Date:   Wed Aug 29 23:15:55 2018 +0800

    BaseTools: Clarify a DSC parsing error about PCDs
    
    This error needs the information about which DEC files were searched.
    
    Cc: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>
    Cc: Liming Gao <liming.gao@xxxxxxxxx>
    Cc: Lee Hamel <lee.m.hamel@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Jaben Carsey <jaben.carsey@xxxxxxxxx>
    Reviewed-by: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel