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

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

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 acc3a3776dc3fb3dc900819b1ee94a6d4f9cf759
baseline version:
 ovmf                 7eb3bb6c552d59b28f07ce5787049b53da76d5cf

Last test of basis    67685  2016-09-09 21:46:28 Z    0 days
Testing same since    67689  2016-09-10 07:17:37 Z    0 days    1 attempts

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

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 acc3a3776dc3fb3dc900819b1ee94a6d4f9cf759
Author: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
Date:   Sun Sep 4 14:16:19 2016 +0100

    OptionRomPkg: .dsc fixes for ARM/AARCH64 and USB drivers
    
    Drivers under OptionRomPkg wouldn't build standalone, since ARM and
    AARCH64 were missing from SUPPORTED_ARCHITECTURES. So add them.
    Also, add some compiler libraries needed for ARM/AARCH64 GCC
    toolchains (CompilerIntrinsicsLib and BaseSwStackCheckLib).
    
    Also, the UsbNetworking drivers were not listed under [Components],
    so failed to build standalone. This patch adds them.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
    Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>

commit 92cec05e27d9eafe188da6a19d97bf6509bc164b
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Wed Sep 7 08:01:31 2016 +0100

    ArmPkg/ArmGicLib: use correct loop variable
    
    The ArmGicLib API function GicGetCpuRedistributorBase () declares
    GicCpuRedistributorBase to iterate over the redistributors of all
    CPUs, but then inadvertently advances GicRedistributorBase instead.
    
    Reported-by: "Oliyil Kunnil, Vishal" <vishalo@xxxxxxxxxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit 1f8f4e33a139845bd73cc1ab2fdfc83e5f0ce56d
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Fri Sep 9 08:28:53 2016 +0100

    ArmPkg/DefaultExceptionHandlerLib: trim module name in backtrace output
    
    As reported by Vishal, the new backtrace output would be more useful if
    it did not contain the full absolute path of each module in the list.
    So strip off everything up to the last forward slash or backslash in the
    string.
    
    Example output:
    
      IRQ Exception at 0x000000005EF110E0
      DxeCore.dll loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EF121F0) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EF1289C) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EEFB6B4) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EEFAA44) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EEFB450) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EEF938C) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EEF8D04) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EEFA8E8) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EEF3C14) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EEF3E48) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EF0C838) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EEEF70C) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EEEE93C) loaded at 0x000000005EEED000
      called from DxeCore.dll (0x000000005EEEE024) loaded at 0x000000005EEED000
    
    Suggested-by: "Oliyil Kunnil, Vishal" <vishalo@xxxxxxxxxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit bdb10148fcf58f03933e9c25c19e618b972f8ccb
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Wed Sep 7 11:32:42 2016 +0100

    ArmPlatformPkg/NorFlashDxe: use strictly aligned CopyMem()
    
    The UEFI spec stipulates that unaligned accesses should be enabled
    on CPUs that support them, which means all of them, given that we
    no longer support pre-v7 ARM cores, and the AARCH64 bindings mandate
    support for unaligned accesses unconditionally.
    
    This means that one should not assume that CopyMem () is safe to call
    on regions that may be mapped using device attributes, which is the
    case for the NOR flash. Since we have no control over the mappings when
    running under the OS, and given that write accesses require device
    mappings, we should not call CopyMem () in the read path either, but
    use our own implementation that is guaranteed to take alignment into
    account.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit 35071e15748fa54809e485935b631dbe58c1f078
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Fri Sep 9 08:17:40 2016 +0100

    MdePkg/BaseLib AARCH64: terminate stack frame list on stack switch
    
    When switching to the DXE phase stack, set the frame pointer to zero so
    that code walking the stack frame will not try to access stack frames
    belonging to the old stack.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit 2d41ea3aed4ea1935fc63df35b834e9626f896df
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Sep 8 21:47:19 2016 +0200

    BaseTools/EfiRom: supply missing machine type lookup strings
    
    "EfiRom --dump" does not recognize the 0x8664 machine type:
    
    >   EFI ROM header contents
    >     EFI Signature          0x0EF1
    >     Compression Type       0x0001 (compressed)
    >     Machine type           0x8664 (unknown)
    >     Subsystem              0x000B (EFI boot service driver)
    >     EFI image offset       0x0050 (@0xF650)
    
    Add lookup strings for the remaining EFI_IMAGE_MACHINE_* numeric macros
    that can be found in
    "BaseTools/Source/C/Include/IndustryStandard/PeImage.h". The strings
    follow Table 12. "UEFI Image Types" from the UEFI v2.6 spec.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Liming Gao <liming.gao@xxxxxxxxx>
    Cc: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>
    Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

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