[Xen-devel] [ovmf baseline-only test] 38340: regressions - FAIL

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

This run is configured for baseline tests only.

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

Regressions :-(

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

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

version targeted for testing:
 ovmf                 3164361121526318f278a7c1b84bdcc475d4ad95
baseline version:
 ovmf                 63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f

Last test of basis    38337  2015-11-24 20:49:54 Z    0 days
Testing same since    38340  2015-11-25 07:51:00 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
  Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
  Wei Huang <wei@xxxxxxxxxx>

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


------------------------------------------------------------
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 3164361121526318f278a7c1b84bdcc475d4ad95
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Tue Nov 24 08:40:33 2015 +0000

    BaseTools/GenFw ARM: allow R_ARM_REL32 relocations
    
    R_ARM_REL32 are relative relocations, so we don't need to do anything
    special when performing the ELF to PE/COFF conversion, since our memory
    layout is identical between the two binary formats. So just allow them.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>
    
    git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18931 
6f19259b-4bc3-4df7-8a09-765794883524

commit 2cde2696f5cd252c48fe250d44590869dae7a1e9
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Tue Nov 24 07:48:06 2015 +0000

    ArmLib/ArmV7Mmu: use 64-bit type for mapping region size
    
    The way the v7 MMU code is invoked by the Xen port is somewhat of
    a pathological case, since it describes its physical memory space
    using a single cacheable region that covers the entire addressable
    range. When clipping this region to the part that is 1:1 addressable,
    we end up with a region of exactly 4 GB in size, which just exceeds
    the range of the UINT32 variable we use in FillTranslationTable() to
    track our progress while populating the page tables. So promote it
    to UINT64 instead.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
    
    git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18930 
6f19259b-4bc3-4df7-8a09-765794883524

commit 1dc3f34f61044a19573b1ecc507081bfcb075739
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Tue Nov 24 07:44:41 2015 +0000

    ArmVirtPkg/ArmVirtPlatformLib: reduce ID map size to GCD region size
    
    The ID mapping routines on virtual platforms simply map the entire
    hardware supported physical address space as device memory, and then
    punch some holes for regions that need to be mapped cacheable.
    On virtual platforms hosted on CPUs that support a large physical
    address range, this may result in a lot of overhead, i.e., 4 KB of page
    tables for each 512 GB of address space, which quickly adds up (i.e.,
    2 MB for the architectural maximum of 48 bits).
    
    Since there may be a platform specific limit to the size of the (I)PA
    space that is not reflected by CPU id registers, restrict the range of
    the ID mapping to gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize bits.
    This makes sense by itself, since we cannot manipulate mappings above
    that limit anwyay (because they are not covered by GCD), and it allows
    the PCD be set to a lower value by platforms whose (I)PA space is
    smaller than the hardware supported maximum.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Tested-by: Wei Huang <wei@xxxxxxxxxx>
    
    git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18929 
6f19259b-4bc3-4df7-8a09-765794883524

commit 7416fd46e330b4ffa7856754dd3f56991f4f67c9
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Tue Nov 24 07:44:28 2015 +0000

    ArmVirtPkg/ArmVirtQemu: limit the (I)PA space to 40 bits
    
    KVM uses a fixed size of 40 bits for its intermediate physical address
    space, so there is no need to support anything beyond that even if the
    host hardware does.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Tested-by: Wei Huang <wei@xxxxxxxxxx>
    
    git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18928 
6f19259b-4bc3-4df7-8a09-765794883524

commit 67b1c254dd17152d28933c5bf7fbefc53676d166
Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
Date:   Tue Nov 24 06:57:47 2015 +0000

    MdeModulePkg/BdsDxe: Fix EBC build failure
    
    Define EFI_REMOVABLE_MEDIA_FILE_NAME for EBC ARCH to fix EBC build failure.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Reviewed-by: Shumin Qiu <shumin.qiu@xxxxxxxxx>
    
    git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18927 
6f19259b-4bc3-4df7-8a09-765794883524

commit 665b26ba331d961cead150fe5b2dde385b9c3988
Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
Date:   Tue Nov 24 06:56:05 2015 +0000

    MdeModulePkg/UefiBootManagerLib: Always create MemoryTypeInfo variable
    
    Align to old BDS behavior (IntelFrameworkModulePkg/BDS) to always create
    MemoryTypeInfo variable regardless of the 
PcdResetOnMemoryTypeInformationChange
    value.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Reviewed-by: Michael Kinney <michael.d.kinney@xxxxxxxxx>
    
    git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18926 
6f19259b-4bc3-4df7-8a09-765794883524

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