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

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

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 02739b0f41300da70369be7c1982180306e8ca95
baseline version:
 ovmf                 279c01ce13739f0fd8ec3e7652299f6873fc14a9

Last test of basis    72016  2017-08-25 05:24:13 Z    0 days
Testing same since    72024  2017-08-25 20:51:03 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
  Hess Chen <hesheng.chen@xxxxxxxxx>
  Laszlo Ersek <lersek@xxxxxxxxxx>
  Leif Lindholm <leif.lindholm@xxxxxxxxxx>
  Liming Gao <liming.gao@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 02739b0f41300da70369be7c1982180306e8ca95
Author: Liming Gao <liming.gao@xxxxxxxxx>
Date:   Thu Aug 24 11:32:23 2017 +0800

    BaseTools: Update tools_def to remove /Gw option in VS NOOPT target
    
    To remove /Gw option is to disable size optimization.
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Liming Gao <liming.gao@xxxxxxxxx>
    Reviewed-by: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>

commit 2f7f1e73c10f9057be27ec6ffe92aaf8084d176f
Author: Liming Gao <liming.gao@xxxxxxxxx>
Date:   Wed Aug 23 16:04:04 2017 +0800

    BaseTools: Add the missing -pie link option in GCC tool chain
    
    https://bugzilla.tianocore.org/show_bug.cgi?id=671
    GCC tool chain uses -fpie in CC_FLAGS. So, add -pie in DLINK_FLAGS.
    More discussion in
    https://lists.01.org/pipermail/edk2-devel/2017-August/013508.html
    
    3.13 Options for Linking
    ========================
    '-pie'
         Produce a position independent executable on targets that support
         it.  For predictable results, you must also specify the same set
         of options used for compilation ('-fpie', '-fPIE', or model
         suboptions) when you specify this linker option.
    
    3.18 Options for Code Generation Conventions
    ============================================
    '-fpie'
    '-fPIE'
         These options are similar to '-fpic' and '-fPIC', but generated
         position independent code can be only linked into executables.
         Usually these options are used when '-pie' GCC option is used
         during linking.
         '-fpie' and '-fPIE' both define the macros '__pie__' and
         '__PIE__'. The macros have the value 1 for '-fpie' and 2 for
         '-fPIE'.
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Liming Gao <liming.gao@xxxxxxxxx>
    Reviewed-by: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>
    Tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit ae9e4650cdf8a7e6790f74e54a9276700dd9d894
Author: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
Date:   Thu Aug 24 17:20:04 2017 +0100

    ArmVirtPkg: drop unused Pcds from ArmVirt.dsc.inc
    
    A block of settings has been copied around ARM platforms for years.
    These are consumed only by Ebl, and since none of the ArmVirtPkg
    platforms use that, drop them.
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit 6650d78558eb567aaeb8a6509fb7d4e4ed621433
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Thu Aug 24 17:57:05 2017 +0100

    ArmPkg/ArmDmaLib: remove dependency on UncachedMemoryAllocationLib
    
    Now that ArmDmaLib no longer uses uncached mappings for short-lived
    bounce buffers used for streaming DMA, the only place we allocate
    uncached memory is in DmaAllocateBuffer (), which is used for static
    mappings shared between the host and the device, e.g., for packet
    descriptor rings etc.
    
    There is no performance concern around such long lived mappings, and
    so we can really do without the overhead of UncachedMemoryAllocationLib,
    which is a sizable chunk of poorly maintained code that never actually
    releases any memory, and despite the fact that it implements pool based
    routines, it always performs page based allocations anyway.
    
    So let's invoke the DXE services directly to manage memory attributes
    on allocations, and keep track of the allocations in a linked list so
    we can restore the attributes and free the memory properly after use.
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

commit bfb0ee0adbb1838a371e9f5b1c1b49e1f354447a
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Thu Aug 24 13:17:48 2017 +0100

    OvmfPkg/QemuVideoDxe: remove AARCH64/ARM support
    
    Now that we have dropped QemuVideoDxe from all QEMU targeted builds
    under ArmVirtPkg, we can revert the ARM specific changes to it.
    
    This partially reverts commits 84a75f70e903 (SVN 16890) and
    05a537945872.
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit f71b163020d7f97e0533c412d175bc642f628ef6
Author: Hess Chen <hesheng.chen@xxxxxxxxx>
Date:   Wed Aug 23 13:53:36 2017 +0800

    BaseTools/UPT: Fix UNI file name issue
    
    Fix the issue of creating duplicate UNI file names
    Fix the issue of removing packages
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Hess Chen <hesheng.chen@xxxxxxxxx>
    Reviewed-by: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>

commit cefbbb3d087143316fba077dd02964afb92f647f
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Tue Aug 22 17:30:13 2017 +0100

    ArmVirtPkg: remove QemuVideoDxe from ArmVirtQemu and ArmVirtQemuKernel
    
    One of the reasons for introducing virtio-gpu support to OvmfPkg and
    ArmVirtpkg was the fact that under KVM virtualization on ARM, the
    legacy VGA cannot be used reliably. This is due to an implementation
    detail of QEMU+KVM, which remaps cached host memory into the guest
    address space as a framebuffer behind a PCI BAR. Given that the purpose
    of a memory mapped framebuffer is its side effects, such BARs should
    never be mapped cacheable in the guest, and the mismatched attributes
    between host and guest result in a loss of coherency, visible as
    corruption in the framebuffer image.
    
    This issue does not occur under TCG emulation, nor did we expect it to
    actually bring down the guest under KVM, and so it was deemed harmless
    to keep support for the VGA device as well. However, as it turns out,
    the fact that the framebuffer BAR is mapped using device semantics by
    default may result in unalignment faults when we use the ordinary string
    copy routines on the contents. In theory, we could work around this by
    remapping the BAR as write combining, but it appears the generic PCI
    bus driver does not actually implement this.
    
    So let's remove the QemuVideoDxe driver altogether. This may result
    in loss of functionality for use cases that rely on the framebuffer
    to be directly addressable (such as EFIFB), but given that this never
    worked reliably under KVM in the first place, let's not let that stop
    us from dropping support for it.
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

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