[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [ovmf baseline-only test] 68127: all pass



This run is configured for baseline tests only.

flight 68127 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68127/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 ff9a1358b3ff98b1c3a9b4b584fca71653a1c9fe
baseline version:
 ovmf                 2b2efe33eaceb3fd2b5c6859dcb5151970dc797b

Last test of basis    68121  2016-11-29 16:19:18 Z    1 days
Testing same since    68127  2016-11-30 04:52:02 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Laszlo Ersek <lersek@xxxxxxxxxx>
  Michael Kinney <michael.d.kinney@xxxxxxxxx>
  Yonghong Zhu <yonghong.zhu@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                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
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.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.

------------------------------------------------------------
commit ff9a1358b3ff98b1c3a9b4b584fca71653a1c9fe
Author: Michael Kinney <michael.d.kinney@xxxxxxxxx>
Date:   Tue Nov 29 01:15:28 2016 -0800

    Vlv2TbltDevicePkg: Fix IA32 boot timeouts
    
    https://bugzilla.tianocore.org/show_bug.cgi?id=264
    
    The IA32 build gets timeouts booting to the UEFI Shell.
    Update the IA32 DSC file to match the X64 DSC file
    disabling the fTPM feature.
    
    Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx>
    Cc: David Wei <david.wei@xxxxxxxxx>
    Cc: Mang Guo <mang.guo@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Michael Kinney <michael.d.kinney@xxxxxxxxx>
    Reviewed-by: Jiewen Yao <jiewen.yao@xxxxxxxxx>

commit 71d86ec879ae573a264eed71dd1bff9d547e70b0
Author: Michael Kinney <michael.d.kinney@xxxxxxxxx>
Date:   Tue Nov 29 01:13:21 2016 -0800

    Vlv2TbltDevicePkg/PlatformFlashAccessLib: Fix IA32 build issues
    
    https://bugzilla.tianocore.org/show_bug.cgi?id=263
    
    Fix IA32 build issues in the PlatformFlashAccessLib.  Some of the
    UINT64 FLASH addresses values need to be typecast to UINTN.
    
    Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx>
    Cc: David Wei <david.wei@xxxxxxxxx>
    Cc: Mang Guo <mang.guo@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Michael Kinney <michael.d.kinney@xxxxxxxxx>
    Reviewed-by: Jiewen Yao <jiewen.yao@xxxxxxxxx>

commit 97e862bbbdd112c0d9523292b0184e74c1a220fc
Author: Michael Kinney <michael.d.kinney@xxxxxxxxx>
Date:   Tue Nov 29 01:11:43 2016 -0800

    Vlv2TbltDevicePkg: Remove SMM binary modules from FDF
    
    https://bugzilla.tianocore.org/show_bug.cgi?id=261
    https://bugzilla.tianocore.org/show_bug.cgi?id=262
    
    Remove the PowerManagement2 binary SMM module that generates an
    ASSERT() and the DigitalThermalSensor binary SMM module that
    causes an AP to be stuck in the busy state.
    
    This is a workaround until these two SMM binary modules can be
    updated.
    
    Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx>
    Cc: David Wei <david.wei@xxxxxxxxx>
    Cc: Mang Guo <mang.guo@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Michael Kinney <michael.d.kinney@xxxxxxxxx>
    Reviewed-by: Jiewen Yao <jiewen.yao@xxxxxxxxx>

commit 890f11d4286b29f008a0deecd2bf01b4d767c118
Author: Michael Kinney <michael.d.kinney@xxxxxxxxx>
Date:   Tue Nov 29 01:05:05 2016 -0800

    Vlv2TbltDevicePkg/PlatformInitPei: Workaround unaligned SMRAM size
    
    https://bugzilla.tianocore.org/show_bug.cgi?id=260
    
    The PiSmmCPuDxeSmm module requires the SMRR base address and length
    to be aligned.  The memory initialization for Vlv2TbltDevicePkg
    produces an SMRAM base address that is on a 16MB boundary and an
    SMRAM length of 12MB.  The SMRAM length is rounded up to 16MB.
    
    This is a workaround until the binary module that produces the
    gEfiSmmPeiSmramMemoryReserveGuid HOB is updated
    
    Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx>
    Cc: David Wei <david.wei@xxxxxxxxx>
    Cc: Mang Guo <mang.guo@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Michael Kinney <michael.d.kinney@xxxxxxxxx>
    Reviewed-by: Jiewen Yao <jiewen.yao@xxxxxxxxx>

commit eadc05bd9237a716dc4c7cbe86806c2e27205ea7
Author: Michael Kinney <michael.d.kinney@xxxxxxxxx>
Date:   Tue Nov 29 00:54:31 2016 -0800

    Vlv2TbltDevicePkg: Set CAPSULE_ENABLE to TRUE
    
    https://bugzilla.tianocore.org/show_bug.cgi?id=259
    
    Set CAPSULE_ENABLE to TRUE so the standard Vlv2TbltDevicePkg
    platform builds can complete.  Build_IFWI.bat assumes this
    flag is TRUE.
    
    Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx>
    Cc: David Wei <david.wei@xxxxxxxxx>
    Cc: Mang Guo <mang.guo@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Michael Kinney <michael.d.kinney@xxxxxxxxx>
    Reviewed-by: Jiewen Yao <jiewen.yao@xxxxxxxxx>

commit 6f5141430b76bb36a0f1f6e501008d1305a4b08b
Author: Michael Kinney <michael.d.kinney@xxxxxxxxx>
Date:   Tue Nov 29 00:51:26 2016 -0800

    Vlv2TbltDevicePkg: Allow BaseTools to run from sources
    
    https://bugzilla.tianocore.org/show_bug.cgi?id=258
    
    Update bld_vlv.bat to run BaseTools build command with a call
    statement to support running the build command from python
    sources.
    
    Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx>
    Cc: David Wei <david.wei@xxxxxxxxx>
    Cc: Mang Guo <mang.guo@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Michael Kinney <michael.d.kinney@xxxxxxxxx>
    Reviewed-by: Jiewen Yao <jiewen.yao@xxxxxxxxx>

commit 8401d3983d00194b5a9aa77cf65477bfc1716588
Author: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>
Date:   Thu Nov 24 23:19:57 2016 +0800

    BaseTools: Fix bug for decimal value of VPDPCD offset display in report
    
    current if we set VPD PCD's offset to a decimal value, eg: 22, this
    value is displayed incorrectly in the "FD VPD Region" section in the
    report.txt.
    
    Cc: Liming Gao <liming.gao@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>

commit 45a70db3c3a59b64e0f517870415963fbfacf507
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Nov 24 15:18:44 2016 +0100

    OvmfPkg/PlatformPei: take VCPU count from QEMU and configure MpInitLib
    
    These settings will allow CpuMpPei and CpuDxe to wait for the initial AP
    check-ins exactly as long as necessary.
    
    It is safe to set PcdCpuMaxLogicalProcessorNumber and
    PcdCpuApInitTimeOutInMicroSeconds in OvmfPkg/PlatformPei.
    OvmfPkg/PlatformPei installs the permanent PEI RAM, producing
    gEfiPeiMemoryDiscoveredPpiGuid, and UefiCpuPkg/CpuMpPei has a depex on
    gEfiPeiMemoryDiscoveredPpiGuid.
    
    It is safe to read the fw_cfg item QemuFwCfgItemSmpCpuCount (0x0005). It
    was added to QEMU in 2008 as key FW_CFG_NB_CPUS, in commit 905fdcb5264c
    ("Add common keys to firmware configuration"). Even if the key is
    unavailable (or if fw_cfg is entirely unavailable, for example on Xen),
    QemuFwCfgRead16() will return 0, and then we stick with the current
    behavior.
    
    Cc: Igor Mammedov <imammedo@xxxxxxxxxx>
    Cc: Jeff Fan <jeff.fan@xxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Michael Kinney <michael.d.kinney@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 6e1987f19af720aa9991f3f9994370383f43222d
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Nov 24 12:19:54 2016 +0100

    UefiCpuPkg/MpInitLib: wait no longer than necessary for initial AP startup
    
    Sometimes a platform knows exactly how many CPUs it has at boot. It should
    be able to
    - set PcdCpuMaxLogicalProcessorNumber dynamically to this number,
    - set PcdCpuApInitTimeOutInMicroSeconds to a very long time (for example
      MAX_UINT32, approx. 71 minutes),
    - and expect that MpInitLib wait exactly as long as necessary for all APs
      to report in.
    
    Other platforms should be able to continue setting a reasonably large
    upper bound on supported CPUs, and waiting for a reasonable, fixed amount
    of time for all APs to report in.
    
    Add this functionality. The TimedWaitForApFinish() function will return
    when all APs have reported in, or the timeout has expired -- whichever
    happens first.
    
    (Accessing these PCDs dynamically is safe. The PEI and DXE phase instances
    of this library are restricted to PEIM and DXE_DRIVER client modules, thus
    the PCD accesses cannot be linked into runtime code.)
    
    Cc: Igor Mammedov <imammedo@xxxxxxxxxx>
    Cc: Jeff Fan <jeff.fan@xxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Michael Kinney <michael.d.kinney@xxxxxxxxx>
    Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=116
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Reviewed-by: Jeff Fan <jeff.fan@xxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.