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

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



This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 ce13d2d8c81f0ba77ac15d1e9a395ef1b8e57a82
baseline version:
 ovmf                 ba40cb31b69df76a3392219a78cbd7b49ae24c49

Last test of basis    71995  2017-08-19 16:49:50 Z    1 days
Testing same since    71996  2017-08-20 15:19:31 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 ce13d2d8c81f0ba77ac15d1e9a395ef1b8e57a82
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Fri Aug 18 04:30:40 2017 +0200

    MdeModulePkg/ScsiBusDxe: don't produce ScsiIo for nonexistent LUNs, part 2
    
    The SPC-4 says about INQUIRY,
    
    > In response to an INQUIRY command received by an incorrect logical unit,
    > the SCSI target device shall return the INQUIRY data with the peripheral
    > qualifier set to the value defined in 6.4.2. The INQUIRY command shall
    > return CHECK CONDITION status only when the device server is unable to
    > return the requested INQUIRY data.
    
    When a device server takes the second branch, and returns CHECK CONDITION
    for a nonexistent LUN, the InquiryData structure in the
    DiscoverScsiDevice() function remains filled with the original zeros.
    
    DiscoverScsiDevice() then sees zero in both Peripheral_Qualifier and
    Peripheral_Type, and therefore ScsiBusDxe produces a ScsiIo protocol
    instance with device type zero, for the nonexistent LUN.
    
    Device type zero is EFI_SCSI_TYPE_DISK. Thus ScsiDiskDxe binds the bogus
    ScsiIo protocol interface, and produces a similarly bogus BlockIo
    interface on top. This ripples up to BDS, where UefiBootManagerLib can
    auto-generate bogus UEFI boot options for the nonexistent LUNs.
    
    This has been encountered with QEMU, after commit ded6ddc5a7b9 ("scsi:
    clarify sense codes for LUN0 emulation", 2017-08-04). QEMU now answers
    INQUIRY commands that were directed to nonexistent LUNs with:
    
    > DiscoverScsiDevice:1361: Lun=2 HostAdapterStatus=0 TargetStatus=2
    >                          SenseDataLength=18 InquiryDataLength=96
    > Sense {
    > Sense 000000 70 00 05 00 00 00 00 0A 00 00 00 00 25 00 00 00
    > Sense 000010 00 00
    > Sense }
    > Inquiry {
    > Inquiry 000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    > Inquiry 000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    > Inquiry 000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    > Inquiry 000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    > Inquiry 000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    > Inquiry 000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    > Inquiry }
    
    The interesting fields are:
    - HostAdapterStatus=0 (OK),
    - TargetStatus=2 (CHECK CONDITION),
    - Sense/Error_Code=0x70 (Current error, Fixed description)
    - Sense/Sense_Key=0x05 (ILLEGAL REQUEST)
    
    According to SPC-4 "Table 41 -- Sense key descriptions (part 2 of 2)",
    ILLEGAL REQUEST is justified when "the command was addressed to an
    incorrect logical unit number".
    
    Thus, recognize this kind of answer for nonexistent LUNs.
    
    (
    
    Checking the status fields and the sense data is justified anyway,
    according to the documentation of ScsiInquiryCommand():
    
    >   @retval EFI_SUCCESS                    The command was executed
    >                                          successfully. See
    >                                          HostAdapterStatus,
    >                                          TargetStatus, SenseDataLength,
    >                                          and SenseData in that order for
    >                                          additional status information.
    
    )
    
    Cc: Eric Dong <eric.dong@xxxxxxxxx>
    Cc: Feng Tian <feng.tian@xxxxxxxxx>
    Cc: Hannes Reinecke <hare@xxxxxxxx>
    Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
    Cc: Star Zeng <star.zeng@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit c09e481bbb34cb781b3d98f4ec781305e61dfda5
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Fri Aug 18 04:07:01 2017 +0200

    MdeModulePkg/ScsiBusDxe: remove redundant "else" after "break" statement
    
    The code after the "if" statement is only reachable if the first branch
    with the "break" is not taken. Therefore we can move the "else" branch
    after the "if" statement, simplifying the code.
    
    Cc: Eric Dong <eric.dong@xxxxxxxxx>
    Cc: Feng Tian <feng.tian@xxxxxxxxx>
    Cc: Hannes Reinecke <hare@xxxxxxxx>
    Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
    Cc: Star Zeng <star.zeng@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit 897efb977ffb23405e15e31533d5487b13873f00
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Fri Aug 18 03:22:06 2017 +0200

    MdeModulePkg/ScsiBusDxe: don't produce ScsiIo for nonexistent LUNs, part 1
    
    The SPC-4 spec says about the INQUIRY data, in "Table 138 -- Peripheral
    qualifier":
    
    > Qualifier = 011b  The device server is not capable of supporting a
    >                   peripheral device on this logical unit. For this
    >                   peripheral qualifier the peripheral device type shall
    >                   be set to 1Fh. All other peripheral device type values
    >                   are reserved for this peripheral qualifier.
    
    Accordingly, the DiscoverScsiDevice() function returns FALSE if
    Peripheral_Qualifier is 3 decimal, but Peripheral_Type differs from 1Fh.
    This is a valid sanity check -- such combinations are reserved.
    
    When Peripheral_Qualifier is 3, and Peripheral_Type is 1Fh, then
    DiscoverScsiDevice() returns TRUE. While this combination is not reserved,
    returning TRUE for it is incorrect: Peripheral_Type 1Fh stands for
    "Unknown or no device type", and this combination is returned in
    particular when the INQUIRY command was directed to a nonexistent LUN.
    Quoting the spec:
    
    > In response to an INQUIRY command received by an incorrect logical unit,
    > the SCSI target device shall return the INQUIRY data with the peripheral
    > qualifier set to the value defined in 6.4.2. [...]
    >
    > [...]
    >
    > The PERIPHERAL QUALIFIER field and PERIPHERAL DEVICE TYPE field identify
    > the peripheral device connected to the logical unit. If the SCSI target
    > device is not capable of supporting a peripheral device connected to
    > this logical unit, the device server shall set these fields to 7Fh
    > (i.e., PERIPHERAL QUALIFIER field set to 011b and PERIPHERAL DEVICE TYPE
    > field set to 1Fh).
    
    The consequence of this bug is that for each nonexistent Target/LUN pair,
    we produce a useless ScsiIo protocol interface. The internal
    "ScsiIoDevice->ScsiDeviceType" field will be set to 0x1f, and it will be
    returned to higher-level SCSI drivers when they call
    ScsiIo->GetDeviceType().
    
    Given that 0x1f means "Unknown or no device type", no higher-level driver
    can ever support it, so these ScsiIo protocol interfaces are useless.
    
    The fix is to return FALSE for the (Peripheral_Qualifier=3,
    Peripheral_Type=0x1f) combination. With that however we reject the whole
    Peripheral_Qualifier=3 space (justifiedly -- see the definition above),
    which lets us simplify the code.
    
    Cc: Eric Dong <eric.dong@xxxxxxxxx>
    Cc: Feng Tian <feng.tian@xxxxxxxxx>
    Cc: Hannes Reinecke <hare@xxxxxxxx>
    Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
    Cc: Star Zeng <star.zeng@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

_______________________________________________
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®.