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

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

This run is configured for baseline tests only.

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

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

Last test of basis    67881  2016-10-14 16:46:16 Z    1 days
Testing same since    67888  2016-10-15 19:48:59 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  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 5b54c92a6537a9b8650c054348702909c5f57f4f
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Sat Oct 15 17:39:44 2016 +0200

    ArmVirtPkg: undo bogus component name and driver diagnostics disablement
    
    The entry point function of any UEFI_DRIVER that conforms to the UEFI
    driver model must install an instance of the EFI_DRIVER_BINDING_PROTOCOL
    on the image handle. Beyond that, the following protocols are optional:
    
    - EFI_COMPONENT_NAME_PROTOCOL
    - EFI_COMPONENT_NAME2_PROTOCOL
    - EFI_DRIVER_CONFIGURATION_PROTOCOL
    - EFI_DRIVER_CONFIGURATION2_PROTOCOL
    - EFI_DRIVER_DIAGNOSTICS_PROTOCOL
    - EFI_DRIVER_DIAGNOSTICS2_PROTOCOL
    
    The UefiLib functions
    
    - EfiLibInstallAllDriverProtocols()
    - EfiLibInstallAllDriverProtocols2()
    - EfiLibInstallDriverBindingComponentName2()
    
    are convenience helpers for such UEFI_DRIVERs. They simplify the
    installation of the above protocols.
    
    The UefiLib instance in "MdePkg/Library/UefiLib/UefiDriverModel.c" allows
    platforms to control these functions through the MdePkg feature PCDs
    
    - PcdComponentNameDisable
    - PcdComponentName2Disable
    - PcdDriverDiagnosticsDisable
    - PcdDriverDiagnostics2Disable
    
    If any of these PCDs are set to TRUE, then the helper functions will not
    install the corresponding protocol interfaces on the image handle, even if
    the driver passes in non-NULL protocol interfaces.
    
    In other words, at build time, a platform can forcibly prevent all drivers
    that employ UefiLib from producing these protocols.
    
    In ArmVirtPkg, that's what we've been doing forever, for no reason at all.
    This is why we haven't been seeing component and driver names from the DH,
    DEVICES, DRIVERS and DEVTREE shell commands, unlike in OvmfPkg.
    
    The default value for all these PCDs is FALSE, in "MdePkg/MdePkg.dec".
    Revert ArmVirtPkg to the sane defaults.
    
    This bug dates back to the inception of ArmVirtPkg (called
    ArmPlatformPkg/ArmVirtualizationPkg at the time).
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Fixes: 6f5872b1f4013f58c6d2f446d885edd6c8ea6d21
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

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