|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [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> _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |