This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm                 <job status>                 broken
 build-i386                      <job status>                 broken
 build-amd64-pvops               <job status>                 broken
 build-i386-pvops                <job status>                 broken
 build-i386-xsm                  <job status>                 broken
 build-amd64                     <job status>                 broken

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 build-amd64                   2 hosts-allocate        broken baseline untested
 build-amd64-pvops             2 hosts-allocate        broken baseline untested
 build-amd64-xsm               2 hosts-allocate        broken baseline untested
 build-i386-pvops              2 hosts-allocate        broken baseline untested
 build-i386-xsm                2 hosts-allocate        broken baseline untested
 build-i386                    2 hosts-allocate        broken baseline untested
 build-amd64-xsm               3 capture-logs          broken baseline untested
 build-amd64                   3 capture-logs          broken baseline untested
 build-i386                    3 capture-logs          broken baseline untested
 build-amd64-pvops             3 capture-logs          broken baseline untested
 build-i386-xsm                3 capture-logs          broken baseline untested
 build-i386-pvops              3 capture-logs          broken baseline untested

version targeted for testing:
 ovmf                 bf453d581ecff2a73128873fd714a07508e2ab11
baseline version:
 ovmf                 153f5c7a93be09403891404c06e5b0e24eb019a3

Last test of basis    74584  2018-04-13 00:27:52 Z    0 days
Testing same since    74587  2018-04-13 03:22:19 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Laszlo Ersek <ler...@redhat.com>
  Steve Capper <steve.cap...@linaro.org>

jobs:
 build-amd64-xsm                                              broken  
 build-i386-xsm                                               broken  
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-libvirt                                          blocked 
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64                          blocked 


------------------------------------------------------------
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

broken-job build-amd64-xsm broken
broken-job build-i386 broken
broken-job build-amd64-pvops broken
broken-job build-i386-pvops broken
broken-job build-i386-xsm broken
broken-job build-amd64 broken
broken-step build-amd64 hosts-allocate
broken-step build-amd64-pvops hosts-allocate
broken-step build-amd64-xsm hosts-allocate
broken-step build-i386-pvops hosts-allocate
broken-step build-i386-xsm hosts-allocate
broken-step build-i386 hosts-allocate
broken-step build-amd64-xsm capture-logs
broken-step build-amd64 capture-logs
broken-step build-i386 capture-logs
broken-step build-amd64-pvops capture-logs
broken-step build-i386-xsm capture-logs
broken-step build-i386-pvops capture-logs

Push not applicable.

------------------------------------------------------------
commit bf453d581ecff2a73128873fd714a07508e2ab11
Author: Laszlo Ersek <ler...@redhat.com>
Date:   Wed Apr 11 23:07:59 2018 +0200

    ArmVirtPkg/ArmVirtQemu: hook NvVarStoreFormattedLib into VariableRuntimeDxe
    
    In spite of both ArmVirtQemu and ArmVirtQemuKernel formatting the variable
    store template at build time, link NvVarStoreFormattedLib into
    VariableRuntimeDxe via NULL class resolution on both platforms. This lets
    us test the depexes implemented in the previous patches.
    
    Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Cc: Leif Lindholm <leif.lindh...@linaro.org>
    Cc: Steve Capper <steve.cap...@linaro.org>
    Cc: Supreeth Venkatesh <supreeth.venkat...@arm.com>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <ler...@redhat.com>
    Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>

commit 8f4833bb305453fb30b886fee96888c4bdedbaa7
Author: Laszlo Ersek <ler...@redhat.com>
Date:   Thu Apr 12 01:37:21 2018 +0200

    ArmVirtPkg/PlatformHasAcpiDtDxe: depend on gEfiVariableArchProtocolGuid
    
    PlatformHasAcpiDtDxe consumes the DynamicHii PCD called
    "gArmVirtTokenSpaceGuid.PcdForceNoAcpi". The PcdGetBool() library call
    terminates in gRT->GetVariable(), in the MdeModulePkg/Universal/PCD/Dxe
    driver. Put "gEfiVariableArchProtocolGuid" on PlatformHasAcpiDtDxe's DEPEX
    so that we not attempt the call before the PCD driver can successfully
    read non-volatile variables.
    
    Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Cc: Leif Lindholm <leif.lindh...@linaro.org>
    Cc: Steve Capper <steve.cap...@linaro.org>
    Cc: Supreeth Venkatesh <supreeth.venkat...@arm.com>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <ler...@redhat.com>
    Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>

commit 221c4f626f357ed9fa5e5133514b339d5378a782
Author: Laszlo Ersek <ler...@redhat.com>
Date:   Thu Apr 12 02:00:13 2018 +0200

    ArmPlatformPkg/PL031RealTimeClockLib: depend on gEfiCpuArchProtocolGuid
    
    The RealTimeClockLib class is declared under EmbeddedPkg, so that
    platforms can provide the internals for the
    EmbeddedPkg/RealTimeClockRuntimeDxe driver. In turn the driver produces
    the Real Time Clock Arch Protocol, without which UEFI drivers cannot be
    dispatched.
    
    The PL031RealTimeClockLib instance calls gDS->SetMemorySpaceAttributes()
    in the LibRtcInitialize() public function. This DXE service depends on the
    CPU Arch Protocol. Add it to the depex.
    
    Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Cc: Leif Lindholm <leif.lindh...@linaro.org>
    Cc: Steve Capper <steve.cap...@linaro.org>
    Cc: Supreeth Venkatesh <supreeth.venkat...@arm.com>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <ler...@redhat.com>
    Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Tested-by: Steve Capper <steve.cap...@linaro.org>
    Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>

commit 96337c6dbbd0873eb611c82cd91483ef198b770b
Author: Laszlo Ersek <ler...@redhat.com>
Date:   Wed Apr 11 22:59:13 2018 +0200

    ArmPlatformPkg/NorFlashDxe: depend on gEfiCpuArchProtocolGuid
    
    NorFlashFvbInitialize() calls gDS->SetMemorySpaceAttributes() to mark the
    varstore flash region as uncached. This DXE service depends on the CPU
    Architectural protocol, and the DXE core is allowed to return
    EFI_NOT_AVAILABLE_YET if it hasn't dispatched ArmPkg/Drivers/CpuDxe
    earlier. Make the dependency explicit.
    
    Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Cc: Leif Lindholm <leif.lindh...@linaro.org>
    Cc: Steve Capper <steve.cap...@linaro.org>
    Cc: Supreeth Venkatesh <supreeth.venkat...@arm.com>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <ler...@redhat.com>
    Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Tested-by: Steve Capper <steve.cap...@linaro.org>
    Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>

commit 6281a2ed3bb3ffe57ed54cabd9a31dcf13b415f8
Author: Laszlo Ersek <ler...@redhat.com>
Date:   Wed Apr 11 22:50:18 2018 +0200

    ArmPlatformPkg/NorFlashDxe: cue the variable driver with NvVarStoreFormatted
    
    The BEFORE depex opcode that we currently use to force ourselves in front
    of the variable driver cannot be combined with other depex opcodes.
    Replace the depex with TRUE, and signal NvVarStoreFormattedLib through the
    installation of "gEdkiiNvVarStoreFormattedGuid".
    
    Platforms that rely on NorFlashDxe to format the variable store (as
    opposed to formatting a variable store template through an FDF file, as
    part of the build) should hook NvVarStoreFormattedLib into the variable
    drivers they use, so that the latter await our cue.
    
    Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Cc: Leif Lindholm <leif.lindh...@linaro.org>
    Cc: Steve Capper <steve.cap...@linaro.org>
    Cc: Supreeth Venkatesh <supreeth.venkat...@arm.com>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <ler...@redhat.com>
    Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Tested-by: Steve Capper <steve.cap...@linaro.org>
    Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>

commit 0f87c53d0d0eb7e7c003e209705ec79264e0852b
Author: Laszlo Ersek <ler...@redhat.com>
Date:   Wed Apr 11 22:18:24 2018 +0200

    ArmPlatformPkg/NorFlashDxe: initialize varstore headers eagerly
    
    The lazy initialization of the varstore FVB makes no longer sense at this
    point:
    
    - "mNorFlashInstanceTemplate.Initialize" is NULL;
    
    - in NorFlashCreateInstance(), we only set Instance->Initialize to
      non-NULL -- namely NorFlashFvbInitialize() -- if the FVB stands for the
      variable store (see "ContainVariableStorage" / "SupportFvb");
    
    - we call Instance->Initialize() from three places:
    
      - from NorFlashWriteSingleBlock(), which is too late for the variable
        read service ("variable write" depends on "variable read");
    
      - from InitializeFvAndVariableStoreHeaders(), but that is only reachable
        from NorFlashFvbInitialize(), i.e. recursively from
        Instance->Initialize() itself;
    
      - and from FvbRead(), which is never called by the variable driver, only
        by the FTW driver. However, the variable driver may read (not write)
        the memory-mapped varstore flash chip before the FTW driver is
        dispatched.
    
    Therefore the lazy initialization is both superfluous and insufficient.
    Initialize the varstore headers eagerly, before we install the FVB
    protocol interface.
    
    Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Cc: Leif Lindholm <leif.lindh...@linaro.org>
    Cc: Steve Capper <steve.cap...@linaro.org>
    Cc: Supreeth Venkatesh <supreeth.venkat...@arm.com>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <ler...@redhat.com>
    Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Tested-by: Steve Capper <steve.cap...@linaro.org>
    Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>

commit 7ab26d51808bd4ffab2510091b062a91cf6a8c81
Author: Laszlo Ersek <ler...@redhat.com>
Date:   Wed Apr 11 20:58:58 2018 +0200

    EmbeddedPkg: introduce NvVarStoreFormattedLib
    
    Some platforms don't format a variable store template at build time;
    instead they format the non-volatile varstore flash chip during boot,
    dynamically. Introduce NvVarStoreFormattedLib to enable such platforms to
    delay the "variable read" service drivers until the platform specific
    module(s) report that the variable store has been formatted.
    
    The platform-specific module that performs the formatting during startup
    is usually an FVB or MM FVB driver. Under the proposed scheme, it becomes
    responsible for installing gEdkiiNvVarStoreFormattedGuid with a NULL
    interface in the protocol database. In turn, the platform DSC will hook
    NvVarStoreFormattedLib into the variable service driver, to make the
    latter wait for the FVB driver. Platforms that need not delay the variable
    service driver like this may still use the same FVB driver;
    gEdkiiNvVarStoreFormattedGuid will simply be ignored.
    
    Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Cc: Leif Lindholm <leif.lindh...@linaro.org>
    Cc: Steve Capper <steve.cap...@linaro.org>
    Cc: Supreeth Venkatesh <supreeth.venkat...@arm.com>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <ler...@redhat.com>
    Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Tested-by: Steve Capper <steve.cap...@linaro.org>
    Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>

commit bacfd6ed8cea295e2d955d13bcd372499a4c6806
Author: Laszlo Ersek <ler...@redhat.com>
Date:   Wed Apr 11 18:52:25 2018 +0200

    ArmPkg/CpuDxe: order CpuDxe after ArmGicDxe via protocol depex
    
    Commit 61a7b0ec634f ("ArmPkg/Gic: force GIC driver to run before CPU arch
    protocol driver", 2018-02-06) explains why CpuDxe should be dispatched
    after ArmGicDxe.
    
    To implement the ordering, we should use a regular protocol depex rather
    than the less flexible AFTER opcode. ArmGicDxe installs
    gHardwareInterruptProtocolGuid and gHardwareInterrupt2ProtocolGuid as one
    of the last actions on its entry point stack; either of those is OK for
    CpuDxe to wait for.
    
    Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Cc: Leif Lindholm <leif.lindh...@linaro.org>
    Cc: Steve Capper <steve.cap...@linaro.org>
    Cc: Supreeth Venkatesh <supreeth.venkat...@arm.com>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <ler...@redhat.com>
    Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Tested-by: Steve Capper <steve.cap...@linaro.org>
    Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>

commit 04f6b66b5e77df031291696569dfd9ba9ac4c367
Author: Laszlo Ersek <ler...@redhat.com>
Date:   Wed Apr 11 18:40:49 2018 +0200

    ArmPkg/ArmGicDxe: annotate protocol usage in "ArmGicDxe.inf"
    
    "ArmGicDxe.inf" currently does not document how the protocols in the
    [Protocols] section are used. Such comments help us analyze behavior, so
    let's add them now.
    
    - gHardwareInterruptProtocolGuid and gHardwareInterrupt2ProtocolGuid are
      always produced on the InterruptDxeInitialize() -> (GicV2DxeInitialize()
      | GicV3DxeInitialize()) -> InstallAndRegisterInterruptService() call
      path.
    
    - gEfiCpuArchProtocolGuid is consumed in the CpuArchEventProtocolNotify()
      protocol notify callback. (Technically this is "conditional"; however
      the firmware cannot work without architectural protocols, so we can call
      it unconditional.)
    
    While at it, drop the gArmGicDxeFileGuid comment from FILE_GUID; we're
    going to make that GUID uninteresting soon.
    
    Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Cc: Leif Lindholm <leif.lindh...@linaro.org>
    Cc: Steve Capper <steve.cap...@linaro.org>
    Cc: Supreeth Venkatesh <supreeth.venkat...@arm.com>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <ler...@redhat.com>
    Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Tested-by: Steve Capper <steve.cap...@linaro.org>
    Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>

commit 534397e53849183d5f7ac1b74219f3634cffa294
Author: Laszlo Ersek <ler...@redhat.com>
Date:   Thu Apr 12 00:03:45 2018 +0200

    Omap35xxPkg/InterruptDxe: replace CPU Arch Protocol depex with notify
    
    In a later patch, we'll modify the depex of
    "ArmPkg/Drivers/CpuDxe/CpuDxe.inf" (currently "AFTER gArmGicDxeFileGuid")
    to "gHardwareInterruptProtocolGuid OR gHardwareInterrupt2ProtocolGuid".
    
    Considering platforms that include "ArmPkg/Drivers/CpuDxe/CpuDxe.inf",
    there are two classes:
    
    (1) The platform gets its gHardwareInterruptProtocolGuid or
        gHardwareInterrupt2ProtocolGuid instance from
        "ArmPkg/Drivers/ArmGic/ArmGicDxe.inf". For such platforms, the
        upcoming CpuDxe change is not a problem, because commit 61a7b0ec634f
        made ArmGicDxe wait for the CPU Arch Protocol with a protocol notify.
    
    (2) The platform gets its hardware interrupt protocol(s) from a different
        driver that has a hard depex on the CPU Arch Protocol. The upcoming
        CpuDxe change would lead to a loop in the DXE dispatch order.
    
    In the edk2 tree, only "BeagleBoardPkg/BeagleBoardPkg.dsc" falls in class
    (2), and the driver in question is "Omap35xxPkg/InterruptDxe". Port (most
    of) commit 61a7b0ec634f to it.
    
    Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Cc: Leif Lindholm <leif.lindh...@linaro.org>
    Cc: Steve Capper <steve.cap...@linaro.org>
    Cc: Supreeth Venkatesh <supreeth.venkat...@arm.com>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <ler...@redhat.com>
    Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
    Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to