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

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

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 dd82465a9f0f0beff0e4d74c6e3192b966853332
baseline version:
 ovmf                 8c0b0b34f7875571ee9d3a2a1a28484cef36d969

Last test of basis    67700  2016-09-12 19:48:41 Z    1 days
Testing same since    67707  2016-09-13 23:20:39 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
  Thomas Huth <thuth@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 dd82465a9f0f0beff0e4d74c6e3192b966853332
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Fri Sep 9 09:01:56 2016 +0100

    ArmPkg/ArmMmuLib: base page table VA size on GCD memory map size
    
    As reported by Eugene, the practice of sizing the address space in the
    virtual memory system based on the maximum address in the table passed
    to ArmConfigureMmu() is problematic, since it fails to take into account
    the fact that the GCD memory space may be extended at a later time, both
    for memory and for MMIO. So instead, choose the VA size identical to the
    GCD memory map size, which is based on PcdPrePiCpuMemorySize on ARM
    systems.
    
    Reported-by: Eugene Cohen <eugene@xxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Eugene Cohen <eugene@xxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit d32702d2c2aa23e828363a7f88829b78ce36c3af
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Fri Sep 9 09:50:21 2016 +0100

    ArmPkg/ArmMmuLib: use a pool allocation for the root table
    
    Currently, we allocate a full page for the root translation table, even
    if the configured translation only requires two entries (16 bytes) for
    the root level, which happens to be the case for a 40 bit VA. Likewise,
    for a 36-bit VA space, the root table only needs 16 entries of 8 bytes
    each, adding up to 128 bytes.
    
    So switch to a pool allocation for the root table if we can, but take into
    account that the architecture requires it to be naturally aligned to its
    size, i.e., a 64 byte table requires 64 byte alignment, whereas pool
    allocations in general are only guaranteed to be aligned to 8 bytes.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit 674e127ef64b07a1e6e6bcc5ecbaead50ea81134
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Fri Sep 9 11:19:18 2016 +0100

    ArmPkg/ArmMmuLib: remove bogus alignment of page allocations
    
    In commit 7d189f99d81c ("ArmPkg/Mmu: Fix bug of aligning new allocated
    page table"), we fixed a flaw in the logic regarding alignment of newly
    allocated translation table pages. However, we all failed to spot that
    aligning page based allocations to page size is rather pointless to
    begin with, so simply allocate a single page each time we add new pages
    to the translation tables.
    
    Also, drop the unnecessary cast.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit e93cb72e597df7b37aad7910787b8ecaeac31382
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Fri Sep 9 10:52:25 2016 +0100

    ArmPkg/ArmMmuLib: deobfuscate GetRootTranslationTableInfo ()
    
    The relations between T0SZ, the number of translation levels and the
    size/alignment of the root table can be expressed in simple arithmetic
    expressions, so get rid of the lookup table.
    
    Note that this disregards the fact that the maximum value of T0SZ is
    39 not 42 (as one would expect for the smallest VA size using 2 levels)
    but since this corresponds to a VA size of 32 MB and 4 MB, respectively,
    neither of which are sufficient to run UEFI, we can safely ignore the
    distinction.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

commit b6b33f67dfc6e81dbbdd10c102f2665e7472cd4d
Author: Thomas Huth <thuth@xxxxxxxxxx>
Date:   Tue Sep 13 10:33:20 2016 +0200

    OvmfPkg: Fix typing errors in header files
    
    Correct some typos in the header files of the OvmfPkg
    (which have been discovered with the codespell utility).
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Thomas Huth <thuth@xxxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>

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