[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 3ef3209d3028b77af9f56f183370e7b67cd7c849
baseline version:
 ovmf                 b10d5ddc0385f39d2c2c62843710b7609a4ca169

Last test of basis    67622  2016-09-01 18:16:25 Z    0 days
Testing same since    67623  2016-09-02 02:46:24 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 3ef3209d3028b77af9f56f183370e7b67cd7c849
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Aug 18 11:51:33 2016 +0200

    ArmVirtPkg: remove PcdKludgeMapPciMmioAsCached
    
    In ARM/AARCH64 guests that run on KVM, we can now use virtio-gpu-pci, so
    PcdKludgeMapPciMmioAsCached is no longer necessary. Standard VGA continues
    to work on TCG without the kludge.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 8731debefd1f0750cd033ce88a83f1d1dce9df3c
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Wed Aug 17 22:45:02 2016 +0200

    OvmfPkg/VirtioGpuDxe: implement EFI_GRAPHICS_OUTPUT_PROTOCOL
    
    In this patch we replace our "dummy" Graphics Output Protocol interface
    with the real one. We exploit that EFI_GRAPHICS_OUTPUT_BLT_PIXEL and
    VirtioGpuFormatB8G8R8X8Unorm have identical representations; this lets us
    forego any pixel format conversions in the guest. For messaging the VirtIo
    GPU device, we use the primitives introduced in the previous patch.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit a66ea3b5578ccebf22c2d1d673273f0dffc84ffa
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Aug 18 17:00:03 2016 +0200

    OvmfPkg/VirtioGpuDxe: provide functions for sending VirtIo GPU commands
    
    In this patch we add a "workhorse" function called VirtioGpuSendCommand(),
    and implement seven simple RPCs atop, for the command types listed in
    "OvmfPkg/Include/IndustryStandard/VirtioGpu.h".
    
    These functions will be called by our EFI_GRAPHICS_OUTPUT_PROTOCOL
    implementation.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit c5f235bbf2ac6ecf9acec023a1840b03cbfb5efd
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Aug 18 01:31:27 2016 +0200

    OvmfPkg/VirtioGpuDxe: initialize and tear down VirtIo GPU device
    
    This patch implements the steps listed in section "3.1.1 Driver
    Requirements: Device Initialization" of the Virtio V1.0 Committee Spec 04.
    The VirtIo GPU is brought up in VirtioGpuDriverBindingStart(), and down in
    VirtioGpuDriverBindingStop().
    
    We also add an ExitBootServices() callback that resets the device. This
    ensures that the device model abandons any guest memory areas when we
    transfer control to the guest OS.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 92f200c2d63c5d27dffbf8d85087028a3fd62ef6
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Tue Aug 16 17:53:33 2016 +0200

    ArmVirtPkg/ArmVirtQemu: include VirtioGpuDxe in the platform DSC/FDF files
    
    At this stage, the driver builds, and suffices for testing binding and
    unbinding.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit b3eab01586174d9408ee54fe17deeae982c6445d
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Tue Aug 16 17:35:52 2016 +0200

    OvmfPkg: include VirtioGpuDxe in the platform DSC/FDF files
    
    At this stage, the driver builds, and suffices for testing binding and
    unbinding.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit a2a4fa66701dd385495e9dec36650be635dd09dc
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Mon Aug 15 15:34:32 2016 +0200

    OvmfPkg/VirtioGpuDxe: introduce with Component Name 2 and Driver Binding
    
    This patch adds the skeleton of the driver: it implements the Component
    Name 2 Protocol and the Driver  Binding Protocol, in accordance with the
    generic and GOP-specific requirements set forth in the UEFI spec and the
    Driver Writers' Guide.
    
    The basic idea is that VGPU_DEV abstracts the virtio GPU device, while the
    single VGPU_GOP that we intend to support at this point stands for "head"
    (aka "scanout") #0.
    
    For now, the Virtio Device Protocol is only used for driver binding; no
    actual virtio operations are done yet. Similarly, we use a "dummy" GOP
    GUID and protocol structure (a plain UINT8 object) for now, so that
    GOP-consuming drivers don't look at what we produce just yet.
    
    The driver is a bit different from the other virtio device drivers written
    thus far:
    
    - It implements the GetControllerName() member of the Component Name 2
      Protocol. (Formatting helpful names is recommended by UEFI.) As a "best
      effort", we format the PCI BDF into the name (a PCI backend is not
      guaranteed by VIRTIO_DEVICE_PROTOCOL). It should provide a more friendly
      experience in the shell and elsewhere.
    
    - This driver seeks to support all RemainingDevicePath cases:
      - NULL: produce all (= one) child handles (= VGPU_GOP heads) at once,
      - End of Device Path Node: produce no child handles,
      - specific ACPI ADR Node: check if it's supportable, and produce it
        (only one specific child controller is supported).
      This is one of the reasons for separating VGPU_GOP from VGPU_DEV.
    
    The driver is a hybrid driver: it produces both child handles (one, to be
    exact), but also installs a structure (VGPU_DEV) directly on the VirtIo
    controller handle, using gEfiCallerIdGuid as protocol GUID. This is a
    trick I've seen elsewhere in edk2 (for example, TerminalDxe), and it is
    necessary for the following reason:
    
    In EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName(), we must be able to
    "cast down" a VirtIo ControllerHandle to our own private data structure
    (VGPU_DEV). That's only possible if we install the structure directly on
    the VirtIo ControllerHandle (thereby rendering the driver a hybrid
    driver), because a child controller with our GOP implementation on it may
    not exist / be passed in there.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 92dc5e9d74c295a1e3a3ef10f1206c3dcb72a58d
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Mon Aug 15 16:26:29 2016 +0200

    OvmfPkg/IndustryStandard: add type definitions for the virtio GPU device
    
    The GPU additions to VirtIo 1.0 are a work in progress. Mark the relevant
    URLs in the source code. Incorporate the absolute minimum from the WIP
    spec that is necessary for implementing a GOP driver.
    
    Add the VIRTIO_SUBSYSTEM_GPU_DEVICE macro to
    "IndustryStandard/Virtio10.h", since all other such macros (dating back to
    VirtIo 0.9.5) are part of "IndustryStandard/Virtio095.h".
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 4fdb585c69d6876f3ca6eab4e4208a5e4ab590ac
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Aug 18 11:33:39 2016 +0200

    OvmfPkg/PlatformBootManagerLib: relax device class requirement for ConOut
    
    This will add virtio-gpu-pci devices to ConOut automatically.
    
    For further benefit, the change also allows OVMF to use the legacy-free /
    secondary VGA adapter (added in QEMU commit 63e3e24d, "vga: add secondary
    stdvga variant") as console.
    
    ArmVirtPkg's PlatformBootManagerLib already filters with IS_PCI_DISPLAY();
    see IsPciDisplay().
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
    Originally-suggested-by: Gerd Hoffmann <kraxel@xxxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 76569ca855916d528fa7abd034e880e114d6d5cd
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Aug 18 13:52:26 2016 +0200

    OvmfPkg/Virtio10Dxe: don't bind virtio-vga
    
    Commit 9399f68ae359 ("OvmfPkg: Virtio10Dxe: non-transitional driver for
    virtio-1.0 PCI devices") created a "competition" between Virtio10Dxe and
    QemuVideoDxe for virtio-vga devices. The binding order between these
    drivers is unspecified, and the wrong order effectively breaks commit
    94210dc95e9f ("OvmfPkg: QemuVideoDxe: add virtio-vga support").
    
    Thus, never bind virtio-vga in Virtio10Dxe; QemuVideoDxe provides better
    compatibility for guest OSes that insist on inheriting a linear
    framebuffer. Users who prefer the VirtIo GPU interface at boot time should
    specify virtio-gpu-pci, which is exactly virtio-vga, minus the VGA
    compatibility (such as the framebuffer).
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
    Fixes: 9399f68ae359234b142c293ad1bef75f470ced30
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 442c2ab81e87766f49a0f5656f39512bf1908028
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Aug 18 11:01:56 2016 +0200

    OvmfPkg/QemuVideoDxe: don't incorrectly bind virtio-gpu-pci
    
    The PCI (Vendor ID, Device ID) pair (0x1af4, 0x1050) stands for both the
    virtio-vga and the virtio-gpu-pci device models of QEMU. They differ in
    two things:
    
    - the former has a VGA-compatibility linear framebuffer on top of the
      latter,
    
    - the former has PCI_CLASS_DISPLAY_VGA device class, while the latter has
      PCI_CLASS_DISPLAY_OTHER.
    
    In commit 94210dc95e9f ("OvmfPkg: QemuVideoDxe: add virtio-vga support"),
    we enabled QemuVideoDxe to drive virtio-vga simply by adding its (Vendor
    ID, Device ID) pair to gQemuVideoCardList. This change inadvertently
    allowed QemuVideoDxe to bind virtio-gpu-pci, which it cannot drive though.
    
    Restrict QemuVideoDxe to PCI_CLASS_DISPLAY_VGA, in order to exclude
    virtio-gpu-pci. For the other cards that QemuVideoDxe drives, this makes
    no difference. (Note that OvmfPkg's PlatformBootManagerLib instance has
    always only added PCI_CLASS_DISPLAY_VGA devices to ConOut; see
    DetectAndPreparePlatformPciDevicePath().)
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
    Fixes: 94210dc95e9f7c6ff4066a9b35a288e6f1c271bf
    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

 

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.

Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.