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

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

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 5d5a19028a55a1fb42c9e4304fc84108d3206296
baseline version:
 ovmf                 f2333c707dd04f069c102bcae004561ec590a3a0

Last test of basis    71063  2017-03-21 07:50:39 Z    3 days
Testing same since    71071  2017-03-21 21:56:19 Z    3 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
  Star Zeng <star.zeng@xxxxxxxxx>

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 5d5a19028a55a1fb42c9e4304fc84108d3206296
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Tue Mar 21 09:12:56 2017 +0000

    ArmVirtPkg/HighMemDxe: check new regions against GCD memory space map
    
    Instead of looking at the PCD gArmTokenSpaceGuid.PcdSystemMemoryBase
    to decide which DT node covers the memory we are already using, query
    the GCD memory space map, which is the authoritative source for this
    kind of information
    
    This fixes a problem observed by Michael on platforms where this PCD
    is of the 'Patchable' type, which means updates to its value do not
    propagate to other modules.
    
    Reported-by: Michael Zimmermann <sigmaepsilon92@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit 60bd1e1269ff93390a90014144a835ad71fe2fa0
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Tue Mar 21 08:47:23 2017 +0000

    ArmVirtPkg/HighMemDxe: use CPU arch protocol to apply memprotect policy
    
    Instead of invoking gDS->SetMemorySpaceAttributes to set the EFI_MEMORY_XP
    attribute on newly added regions, which is guaranteed to fail if the same
    attribute was not declared as a capability of the region when it as added,
    invoke the CPU arch protocol directly to set the EFI_MEMORY_XP attribute
    if our memory protection policy demands it.
    
    Reported-by: Michael Zimmermann <sigmaepsilon92@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit 09da11081915dea25d2d1bba87cdf460102e52bb
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Sun Mar 19 17:19:48 2017 +0000

    MdeModulePkg/BootGraphicsResourceTableDxe: don't allocate below 4 GB
    
    The BGRT table has an 8 byte field for the memory address of the image
    data, and yet the driver explicitly allocates below 4 GB. This results
    in an ASSERT() on systems that do not have any memory below 4 GB to begin
    with.
    
    Since neither the PI, the UEFI or the ACPI spec contain any mention of
    why this data should reside below 4 GB, replace the allocation call
    with an ordinary AllocatePages() call.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>

commit f859c6796f4064e2142d4bfaae55dbd3aaf70c55
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Mon Mar 20 14:51:36 2017 +0000

    MdeModulePkg/AcpiTableDxe: consider version mask when removing tables
    
    Invocations of EFI_ACPI_TABLE_PROTOCOL::UninstallAcpiTable() may
    result in a crash when the value of PcdAcpiExposedTableVersions does
    not include EFI_ACPI_TABLE_VERSION_1_0B.
    
    The reason is that EFI_ACPI_TABLE_PROTOCOL::InstallAcpiTable() will
    only populate the Rsdt1/Rsdt3 pointers when EFI_ACPI_TABLE_VERSION_1_0B
    is set, whereas EFI_ACPI_TABLE_PROTOCOL::UninstallAcpiTable() will
    invoke PublishTables with EFI_ACPI_TABLE_VERSION_1_0B alawys set,
    resulting in a NULL pointer dereference of the Rsdt1/Rsdt3 pointers.
    
    So take PcdAcpiExposedTableVersions into account for UninstallAcpiTable
    as well.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit 7043a90eee1150db1d55cdde2a98700fa10838e5
Author: Star Zeng <star.zeng@xxxxxxxxx>
Date:   Fri Mar 17 11:27:37 2017 +0800

    MdeModulePkg CapsuleApp: Add -NR (no-reset) option support
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=388
    
    Add -NR (no-reset) option support, once the option is specified,
    no reset will be trigger for the capsule with flag
    CAPSULE_FLAGS_PERSIST_ACROSS_RESET and no CAPSULE_FLAGS_INITIATE_RESET.
    
    Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx>
    Cc: Xiaofeng Wang <winggundum82@xxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Star Zeng <star.zeng@xxxxxxxxx>
    Reviewed-by: Jiewen Yao <jiewen.yao@xxxxxxxxx>

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