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

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

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e
baseline version:
 ovmf                 85520606ad459ba7d825c7ea5f225cffa1dbe95b

Last test of basis    68597  2017-02-21 21:47:29 Z    0 days
Testing same since    68602  2017-02-22 10:16:50 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
  Jiewen Yao <jiewen.yao@xxxxxxxxx>
  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 e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Wed Feb 15 17:11:56 2017 +0000

    ArmPkg/ArmMmuLib: AARCH64: add support for modifying only permissions
    
    Since the new DXE page protection for PE/COFF images may invoke
    EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes() with only permission
    attributes set, add support for this in the AARCH64 MMU code.
    
    Move the EFI_MEMORY_CACHETYPE_MASK macro to a shared location between
    CpuDxe and ArmMmuLib so we don't have to introduce yet another
    definition.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit 0a9d732c91d99dcd06432722f76b170592b71abc
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Wed Feb 15 17:11:55 2017 +0000

    ArmPkg/CpuDxe: ARM: ignore page table updates that only change permissions
    
    Currently, we have not implemented support on 32-bit ARM for managing
    permission bits in the page tables. Since the new DXE page protection
    for PE/COFF images may invoke EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes()
    with only permission attributes set, let's simply ignore those for now.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit ce82984fe77cd6583f5e8bf2f6fd98262834f834
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Wed Feb 15 17:11:54 2017 +0000

    ArmPkg/CpuDxe: translate invalid memory types in EfiAttributeToArmAttribute
    
    The single user of EfiAttributeToArmAttribute () is the protocol
    method EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes(), which uses the
    return value to compare against the ARM attributes of an existing mapping,
    to infer whether it is actually necessary to change anything, or whether
    the requested update is redundant. This saves some cache and TLB
    maintenance on 32-bit ARM systems that use uncached translation tables.
    
    However, EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes() may be invoked with
    only permission bits set, in which case the implied requested action is to
    update the permissions of the region without modifying the cacheability
    attributes. This is currently not possible, because
    EfiAttributeToArmAttribute () ASSERT()s [on AArch64] on Attributes arguments
    that lack a cacheability bit.
    
    So let's simply return TT_ATTR_INDX_MASK (AArch64) or
    TT_DESCRIPTOR_SECTION_TYPE_FAULT (ARM) in these cases (or'ed with the
    appropriate permission bits). This way, the return value is equally
    suitable for checking whether the attributes need to be modified, but
    in a way that accommodates the use without a cacheability bit set.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit b7a09b71b67cf2d64e90d686c3525a8022bd5579
Author: Jiewen Yao <jiewen.yao@xxxxxxxxx>
Date:   Wed Feb 8 23:20:30 2017 -0800

    ArmPkg/CpuDxe: Correct EFI_MEMORY_RO usage
    
    Current Arm CpuDxe driver uses EFI_MEMORY_WP for write protection,
    according to UEFI spec, we should use EFI_MEMORY_RO for write protection.
    The EFI_MEMORY_WP is the cache attribute instead of memory attribute.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Jiewen Yao <jiewen.yao@xxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
    Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

commit df73df138d9d53f7f7570f4fe97a6cde941a2656
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Feb 9 17:32:40 2017 +0100

    OvmfPkg/AcpiPlatformDxe: replay QEMU_LOADER_WRITE_POINTER commands at S3
    
    Ultimately, each QEMU_LOADER_WRITE_POINTER command creates a guest memory
    reference in some QEMU device. When the virtual machine is reset, the
    device willfully forgets the guest address, since the guest memory is
    wholly invalidated during platform reset.
    
    ... Unless the reset is part of S3 resume. Then the guest memory is
    preserved intact, and the firmware must reprogram those devices with the
    original guest memory allocation addresses.
    
    This patch accumulates the fw_cfg select, skip and write operations of
    ProcessCmdWritePointer() in a validated / condensed form, and turns them
    into an ACPI S3 Boot Script fragment at the very end of
    InstallQemuFwCfgTables().
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 9965cbd424f22b35e7743c2f59ab3ee1db15142a
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Wed Feb 8 21:53:02 2017 +0100

    OvmfPkg/AcpiPlatformDxe: implement the QEMU_LOADER_WRITE_POINTER command
    
    The QEMU_LOADER_WRITE_POINTER command instructs the firmware to write the
    address of a field within a previously allocated/downloaded fw_cfg blob
    into another (writeable) fw_cfg file at a specific offset.
    
    Put differently, QEMU_LOADER_WRITE_POINTER propagates, to QEMU, the
    address that QEMU_LOADER_ALLOCATE placed the designated fw_cfg blob at, as
    adjusted for the given field inside the allocated blob.
    
    The implementation is similar to that of QEMU_LOADER_ADD_POINTER. Since
    here we "patch" a pointer object in "fw_cfg file space", not guest memory
    space, we utilize the QemuFwCfgSkipBytes() and QemuFwCfgWriteBytes() APIs
    completed in commit range 465663e9f128..7fcb73541299.
    
    An interesting aspect is that QEMU_LOADER_WRITE_POINTER creates a
    host-level reference to a guest memory location. Therefore, if we fail to
    process the linker/loader script for any reason, we have to clear out
    those references first, before we release the guest memory allocations in
    response to the error.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit ab63766baf3d46ed0d61af58b74d044936129e8b
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Wed Feb 8 14:15:01 2017 +0100

    OvmfPkg/AcpiPlatformDxe: rewrap license block in "QemuFwCfgAcpi.c"
    
    The longest line is currently 84 characters long.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 774f52f6debdc3ba4e43bb6f49b1223ca727241b
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Wed Feb 8 17:14:34 2017 +0100

    OvmfPkg/AcpiPlatformDxe: add QEMU_LOADER_WRITE_POINTER definitions
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 75ccd1d89e78d4aa3ba3facbdada897149ff7091
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Wed Feb 8 14:25:01 2017 +0100

    OvmfPkg/AcpiPlatformDxe: prepare for QEMU_LOADER_WRITE_POINTER definitions
    
    No functional changes in this patch, just prepare the grounds with some
    reformatting (trailing comma after the last enumeration constant,
    horizontal whitespace insertion) so that the next patch can be cleaner.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
    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