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

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

This run is configured for baseline tests only.

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

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 75106
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install      fail like 75106

version targeted for testing:
 ovmf                 0442a9a9f42abed9f2e44e63115a3abb0d123459
baseline version:
 ovmf                 cc6939067008c4dcab990d5e8be65086ec393afa

Last test of basis    75106  2018-08-22 12:29:11 Z    1 days
Testing same since    75109  2018-08-23 04:54:51 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Bi, Dandan <dandan.bi@xxxxxxxxx>
  Chasel Chiu <chasel.chiu@xxxxxxxxx>
  Chasel, Chiu <chasel.chiu@xxxxxxxxx>
  Dandan Bi <dandan.bi@xxxxxxxxx>
  Laszlo Ersek <lersek@xxxxxxxxxx>
  Songpeng Li <songpeng.li@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 0442a9a9f42abed9f2e44e63115a3abb0d123459
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Fri Aug 17 15:21:34 2018 +0200

    UefiCpuPkg/PiSmmCpuDxeSmm: clear exec file mode bits on "PiSmmCpuDxeSmm.c"
    
    Commit 241f914975d5 ("UefiCpuPkg/PiSmmCpuDxeSmm: Add support for PCD
    PcdPteMemoryEncryptionAddressOrMask", 2017-03-01) unintentionally set the
    executable file mode bits on "PiSmmCpuDxeSmm.c"; clear them now.
    
    Cc: Eric Dong <eric.dong@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1092
    Fixes: 241f914975d50e34f6da57d1e5ac60eedb5d52de
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit 6896efdec2709e530b23c688cf0f31706709a0c5
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Fri Aug 17 15:12:38 2018 +0200

    NetworkPkg/TlsAuthConfigDxe: fix TlsCaCertificate attributes retrieval
    
    Per spec, the GetVariable() runtime service is not required to populate
    (*Attributes) on output when it fails with EFI_BUFFER_TOO_SMALL.
    
    Therefore we have to fetch the full contents of the TlsCaCertificate
    variable temporarily, just so we can (a) get the current attributes, and
    (b) add EFI_VARIABLE_APPEND_WRITE to them for the subsequent SetVariable()
    call.
    
    Cc: Jiaxin Wu <jiaxin.wu@xxxxxxxxx>
    Cc: Siyuan Fu <siyuan.fu@xxxxxxxxx>
    Cc: Songpeng Li <songpeng.li@xxxxxxxxx>
    Reported-by: Songpeng Li <songpeng.li@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1090
    Fixes: b90c335fbbb674470fbf09601cc522bf61564c30
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Tested-by: Songpeng Li <songpeng.li@xxxxxxxxx>
    Reviewed-by: Wu Jiaxin <jiaxin.wu@xxxxxxxxx>
    Reviewed-by: Fu Siyuan <siyuan.fu@xxxxxxxxx>

commit d00759b212e7912113d9c3292c0174c6dbf74842
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Fri Aug 17 15:06:35 2018 +0200

    IntelFrameworkPkg/FrameworkUefiLib: don't special-case EFI_FILE_MODE_CREATE
    
    Synchronize EfiOpenFileByDevicePath() with the MdePkg/UefiLib instance, as
    described in the previous patch.
    
    Cc: Liming Gao <liming.gao@xxxxxxxxx>
    Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Suggested-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1074
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>

commit 5dbc768f1cd988b87932ba2f176caa006064018d
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Fri Aug 17 14:55:23 2018 +0200

    MdePkg/UefiLib: don't special-case EFI_FILE_MODE_CREATE in OpenMode
    
    While reviewing the patch that would land as 768b611136d0
    ("MdePkg/UefiLib: introduce EfiOpenFileByDevicePath()", 2018-08-16), Ray
    pointed out that distinguishing EFI_FILE_MODE_CREATE was wasteful. Per
    spec, if the file to create exists, then EFI_FILE_MODE_CREATE is ignored
    by EFI_FILE_PROTOCOL.Open(), and the existent file is opened.
    
    Therefore we don't need an attempt to "open-but-not-create" first, and a
    fallback to "open-and-create-too" second -- that behavior is internal to
    EFI_FILE_PROTOCOL.Open(). Remove the special-casing of
    EFI_FILE_MODE_CREATE.
    
    Cc: Liming Gao <liming.gao@xxxxxxxxx>
    Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Suggested-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1074
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>

commit e0c93c9b76153bc5a95bf174dab9805ec2f2942c
Author: Bi, Dandan <dandan.bi@xxxxxxxxx>
Date:   Tue Aug 21 16:56:39 2018 +0800

    MdeModulePkg/SmmCorePerfLib: Add DxeServicesLib library class in INF
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1100
    
    SmmCorePerformanceLib consume the DxeServicesLib, but miss to
    add the library class in INF file.
    This patch is to fix this issue.
    
    Cc: Liming Gao <liming.gao@xxxxxxxxx>
    Cc: Star Zeng <star.zeng@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Dandan Bi <dandan.bi@xxxxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit 14a6beac3bcb69f3a01a8a6efbf87008c63b60f0
Author: Chasel, Chiu <chasel.chiu@xxxxxxxxx>
Date:   Wed Aug 22 09:41:25 2018 +0800

    IntelFsp2WrapperPkg: Add EFIAPI to AsmExecute32BitCode
    
    AsmExecute32BitCode is assembly code and needs EFIAPI
    
    Cc: Jiewen Yao <Jiewen.yao@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Chasel Chiu <chasel.chiu@xxxxxxxxx>
    Reviewed-by: Jiewen Yao <Jiewen.yao@xxxxxxxxx>

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