[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 17cbf7359f04a4eb762b2b4bc26c2df635ef2812
baseline version:
 ovmf                 f29ca8e8b96adc2539f44d41ed8521ef6d29c14c

Last test of basis    72047  2017-09-01 00:48:06 Z    0 days
Testing same since    72050  2017-09-01 07:49:12 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
  Brijesh Singh <brijesh.singh@xxxxxxx>
  Laszlo Ersek <lersek@xxxxxxxxxx>
  Leif Lindholm <leif.lindholm@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 17cbf7359f04a4eb762b2b4bc26c2df635ef2812
Author: Brijesh Singh <brijesh.singh@xxxxxxx>
Date:   Thu Aug 31 10:25:27 2017 -0400

    OvmfPkg/VirtioScsiDxe: negotiate VIRTIO_F_IOMMU_PLATFORM
    
    VirtioScsiDxe driver has been updated to use IOMMU-like member functions
    from VIRTIO_DEVICE_PROTOCOL to translate the system physical address to
    device address. We do not need to do anything special when
    VIRTIO_F_IOMMU_PLATFORM bit is present hence treat it in parallel with
    VIRTIO_F_VERSION_1.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Tom Lendacky <thomas.lendacky@xxxxxxx>
    Cc: Laszlo Ersek <lersek@xxxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Brijesh Singh <brijesh.singh@xxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Regression-tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit 9d0d5050c73b142ea03c82cd078be8c703a556f4
Author: Brijesh Singh <brijesh.singh@xxxxxxx>
Date:   Thu Aug 31 10:25:27 2017 -0400

    OvmfPkg/VirtioScsiDxe: map virtio-scsi request and response buffers
    
    When device is behind the IOMMU, driver is require to pass the device
    address of virtio request, response and any memory referenced by those
    request/response to the bus master.
    
    The patch uses IOMMU-like member functions from VIRTIO_DEVICE_PROTOCOL to
    map request and response buffers system physical address to the device
    address.
    
    - If the buffer need to be accessed by both the processor and a bus
      master then map with BusMasterCommonBuffer.
    
    - If the buffer need to be accessed for a write operation by a bus master
      then map with BusMasterWrite.
    
      However, after a BusMasterWrite Unmap() failure, error reporting via
      EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET would be very complex,
      therefore we map such buffers too with BusMasterCommonBuffer.
    
    - If the buffer need to be accessed for a read  operation by a bus master
      then map with BusMasterRead.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Tom Lendacky <thomas.lendacky@xxxxxxx>
    Cc: Laszlo Ersek <lersek@xxxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Brijesh Singh <brijesh.singh@xxxxxxx>
    [lersek@xxxxxxxxxx: restore lost sentence/paragraph in commit message]
    [lersek@xxxxxxxxxx: reindent/reflow "InDataBuffer" comment block]
    [lersek@xxxxxxxxxx: cast arg, not result, of EFI_SIZE_TO_PAGES() to UINTN]
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Regression-tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit 1b15eb06c7f2687ee92cf90f1581c7044691d71f
Author: Brijesh Singh <brijesh.singh@xxxxxxx>
Date:   Thu Aug 31 10:25:27 2017 -0400

    OvmfPkg/VirtioScsiDxe: add helper to create a fake host adapter error
    
    When virtio request fails we return EFI_DEVICE_ERROR, as per the spec
    EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru() member function is required
    to implement elaborated error reporting.
    
    The patch refactors out entire block of the code that creates the host
    adapter error into a separate helper function (ReportHostAdapterError).
    
    Suggested-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Tom Lendacky <thomas.lendacky@xxxxxxx>
    Cc: Laszlo Ersek <lersek@xxxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Brijesh Singh <brijesh.singh@xxxxxxx>
    [lersek@xxxxxxxxxx: fix style & typo in ReportHostAdapterError() comment]
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Regression-tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit fc2168feb24827b3691d85a00f23c35ac4eb2910
Author: Brijesh Singh <brijesh.singh@xxxxxxx>
Date:   Thu Aug 31 10:25:26 2017 -0400

    OvmfPkg/VirtioScsiDxe: map VRING using VirtioRingMap()
    
    When device is behind the IOMMU then driver need to pass the device
    address when programing the bus master. The patch uses VirtioRingMap() to
    map the VRING system physical address to device address.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Tom Lendacky <thomas.lendacky@xxxxxxx>
    Cc: Laszlo Ersek <lersek@xxxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Brijesh Singh <brijesh.singh@xxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Regression-tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit fefeb416e63bf77aa809c2251571cd323c3ad60a
Author: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
Date:   Thu Aug 31 15:31:22 2017 +0100

    ShellBinPkg: AARCH64/ARM Shell binary update.
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
    Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

commit dcd48d2db4eb2d3d93106ad788a0f67d2ca5495c
Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Date:   Thu Aug 24 20:37:01 2017 +0100

    ArmPkg: remove UncachedMemoryAllocationLib
    
    Now that ArmDmaLib can take care of its own memory allocation needs,
    let's get rid of UncachedMemoryAllocationLib entirely. This forces
    platforms to declare the required semantics (non-cache coherent DMA,
    whichever way it is implemented), rather than using uncached memory
    allocations directly, which may not always be the right choice, and
    prevents sharing of drivers between platforms if one is cache coherent
    and the other is not.
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx>

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

 


Rackspace

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