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

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



This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 d74135cd0f8d00d2126df0b4db54938c96456db6
baseline version:
 ovmf                 4ac14ceae076439dcea926bc47cda4e1d2779cae

Last test of basis    67674  2016-09-08 11:48:48 Z    0 days
Testing same since    67675  2016-09-08 16:16:16 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
  Dennis Chen <dennis.chen@xxxxxxx>
  Laszlo Ersek <lersek@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 d74135cd0f8d00d2126df0b4db54938c96456db6
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Thu Sep 8 09:05:45 2016 +0100

    ArmPlatformPkg: remove EFI_MEMORY_UC attribute from normal memory
    
    On ARM systems, mapping normal memory as device memory may have unintended
    side effects, given that unaligned accesses or loads and stores with special
    semantics (e.g., load/store exclusive) may fault or may not work as 
expected.
    Similarly, DC ZVA instructions are only supported on normal memory, not
    device memory.
    
    So remove the EFI_MEMORY_UC attribute that we set by default on system RAM.
    If any region requires this attribute, it is up to the driver to set this
    attribute, and to ensure that no offending operations are performed on it.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit f2509d6d3efbed3cf90c44ace94a331b912b0017
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Thu Sep 8 08:40:09 2016 +0100

    ArmVirtPkg: restrict mapping attributes of normal memory to EFI_MEMORY_WB
    
    In general, on an ARM system, mapping normal memory as device memory may
    have unintended side effects, given that unaligned accesses or loads and
    stores with special semantics (e.g., load/store exclusive) may fault or
    may not work as expected.
    
    Under KVM, the situation is even worse, since the host may not expect the
    guest to perform uncached accesses, and so writes to such an uncached
    region may get lost completely.
    
    Since the only safe mapping type under KVM is EFI_MEMORY_WB, remove all
    other memory type attributes.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit 2bdf3f2ca78eae4abcaa058c0ff4f590c215dd82
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Mon Sep 5 11:53:57 2016 +0100

    ArmPkg/ArmLib: remove all ArmLib flavors except ArmBaseLib
    
    This removes the following ArmLib implementation, which were, apart from
    the fact that they targeted either ARM or AARCH64, fully identical:
    
      ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf
      ArmPkg/Library/ArmLib/AArch64/AArch64LibPei.inf
      ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf
      ArmPkg/Library/ArmLib/AArch64/AArch64LibSec.inf
      ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf
      ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf
      ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf
    
    Only ArmBaseLib remains, which can fulfil the dependencies upon each of
    the listed flavors.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit 550eaa4a76fcac0c2db90e6fd6620bff497f03d8
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Mon Sep 5 11:48:17 2016 +0100

    ArmVirtPkg: replace all ArmLib resolutions with ArmBaseLib
    
    The various ArmLib flavors are identical in practice, and a new
    ArmBaseLib has been introduced that can replace all of them. So replace
    all occurrences with ArmBaseLib.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit 4af5227cdefb1748fd1bfef43c89800f0d8e1d5e
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Mon Sep 5 11:49:37 2016 +0100

    BeagleBoardPkg EmbeddedPkg Omap35xxPkg: move to ArmBaseLib
    
    The various ArmLib flavors are identical in practice, and a new
    ArmBaseLib has been introduced that can replace all of them. So replace
    all occurrences with ArmBaseLib.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit c52c592a0318ea31f14f09ebffa282dbc94f2e76
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Mon Sep 5 11:25:18 2016 +0100

    ArmPkg/ArmLib: introduce ArmBaseLib
    
    Introduce a new ArmLib version ArmBaseLib, which encapsulates the ARM
    version ArmV7Lib and the AArch64 version AArch64Lib.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit 2ede1ac0cc746d17251361176657b5c8a91e3b7e
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Mon Sep 5 11:13:19 2016 +0100

    ArmPkg/ArmLib: remove NullArmLib
    
    Remove the NULL instance of ArmLib: it is not currently used, and its
    usefulness its dubious.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit 8a1f2378d74390ddfe35c70f68e0c8b03bf84089
Author: Dennis Chen <dennis.chen@xxxxxxx>
Date:   Mon Sep 5 19:38:20 2016 +0800

    ArmPkg ArmPlatformPkg ArmVirtPkg: ARM GICv2/v3 Base Address width fix-up
    
    According to the ACPI 6.0/6.1 spec, the physical base address of GICC,
    GICD, GICR and GIC ITS is 64-bit. So change the type of the various GIC
    base address PCDs to 64-bit, and fix up all users.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
    Signed-off-by: Dennis Chen <dennis.chen@xxxxxxx>
    Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

commit d796d33f1844deb492bc571c7f2e2b6780b92368
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Wed Sep 7 12:47:19 2016 +0200

    OvmfPkg/QemuBootOrderLib: drop too strict "/HD(" suffix from vblk prefix
    
    Translating QEMU's virtio-block OpenFirmware device path to a UEFI device
    path prefix was one of the earliest case handled in QemuBootOrderLib. At
    that time, I terminated the translation output (the UEFI devpath prefix)
    with a "/HD(" suffix.
    
    The intent was for the translation to prefix-match only boot options with
    HD() device path nodes in them, that is, no auto-generated "device level"
    boot options. This was motivated by prioritizing specific boot options
    created by OS installers over auto-generated "device level" options.
    
    However, practice has shown that:
    
    - OS installers place their installed boot options first in the boot order
      anyway,
    
    - other device types (SATA disks, virtio-scsi disks), where "/HD(" is not
      appended, work just fine,
    
    - requiring "/HD(" actually causes problems: after the OS-installed
      specific boot option has been lost (or purposely removed), the
      auto-generated "device level" boot option does the right thing (see the
      Default Boot Behavior under
      
<http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/>).
      The "/HD(" requirement causes such boot options to be dropped, which
      prevents "fallback.efi" from running.
    
    Relax the matching by removing the "/HD(" suffix from the translated
    prefix.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Fixes: e06a4cd134064590aa1a855ff4b973023279e805
    Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1373812
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@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®.