[ovmf test] 110117: regressions - FAIL

[osstest service owner <osstest-admin@xxxxxxxxxxxxxx>]

flight 110117 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110117/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm               5 xen-build                fail REGR. vs. 110078
 build-amd64                   5 xen-build                fail REGR. vs. 110078
 build-i386                    5 xen-build                fail REGR. vs. 110078
 build-i386-xsm                5 xen-build                fail REGR. vs. 110078

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a

version targeted for testing:
 ovmf                 4275f38507a4a44260555495dfb6da1d8a307307
baseline version:
 ovmf                 b941c34ef859971e29683ffb57c309e24e6a96be

Last test of basis   110078  2017-06-07 10:03:04 Z    1 days
Testing same since   110104  2017-06-08 00:46:13 Z    0 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
  Laszlo Ersek <lersek@xxxxxxxxxx>

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


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Not pushing.

------------------------------------------------------------
commit 4275f38507a4a44260555495dfb6da1d8a307307
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Sat Jun 3 16:11:08 2017 +0200

    OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted
    
    ... by narrower than 8-byte ADD_POINTER references.
    
    Introduce the CollectAllocationsRestrictedTo32Bit() function, which
    iterates over the linker/loader script, and collects the names of the
    fw_cfg blobs that are referenced by QEMU_LOADER_ADD_POINTER.PointeeFile
    fields, such that QEMU_LOADER_ADD_POINTER.PointerSize is less than 8. This
    means that the pointee blob's address will have to be patched into a
    narrower-than-8 byte pointer field, hence the pointee blob must not be
    allocated from 64-bit address space.
    
    In ProcessCmdAllocate(), consult these restrictions when setting the
    maximum address for gBS->AllocatePages(). The default is now MAX_UINT64,
    unless restricted like described above to the pre-patch MAX_UINT32 limit.
    
    In combination with Ard's QEMU commit cb51ac2ffe36 ("hw/arm/virt: generate
    64-bit addressable ACPI objects", 2017-04-10), this patch enables
    OvmfPkg/AcpiPlatformDxe to work entirely above the 4GB mark.
    
    (An upcoming / planned aarch64 QEMU machine type will have no RAM under
    4GB at all. Plus, moving the allocations higher is beneficial to the
    current "virt" machine type as well; in Ard's words: "having all firmware
    allocations inside the same 1 GB (or 512 MB for 64k pages) frame reduces
    the TLB footprint".)
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx>
    Cc: Igor Mammedov <imammedo@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Suggested-by: Igor Mammedov <imammedo@xxxxxxxxxx>
    Suggested-by: Gerd Hoffmann <kraxel@xxxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

_______________________________________________
osstest-output mailing list
osstest-output@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output