Laszlo, Thanks for your details. It looks make sense.
Reviewed-by: Feng Tian <[email protected]> Thanks Feng -----Original Message----- From: edk2-devel [mailto:[email protected]] On Behalf Of Laszlo Ersek Sent: Thursday, May 5, 2016 12:47 AM To: Tian, Feng <[email protected]>; edk2-devel-01 <[email protected]> Cc: Ni, Ruiyu <[email protected]>; Paolo Bonzini <[email protected]>; Zeng, Star <[email protected]> Subject: Re: [edk2] [PATCH] MdeModulePkg: ScsiDiskDxe: cope with broken "Supported VPD Pages" VPD page On 05/04/16 18:03, Laszlo Ersek wrote: > On 05/04/16 13:11, Laszlo Ersek wrote: >> On 05/04/16 02:58, Tian, Feng wrote: >>> Laszlo, >>> >>> Could you explain more? >>> >>> Usb Flash drive is managed by UsbMassStorage driver, which is irrelevant >>> with UefiScsiLib lib or ScsiDisk driver. >> >> Yeah, sorry about missing that part of the context. >> >> So, the environment is the following: >> >> - The USB flash drive with VendorId/ProductId 0x1516/0x6221 is >> plugged into a Linux host. >> >> - The usb-storage driver in Linux presents the USB flash drive to the >> rest of the system as a SCSI disk. The device node that is generated >> for it looks like /dev/sd*, for example, /dev/sdi. >> >> - This device node can be used like any other SCSI device. >> >> - Using the virtio-scsi HBA, QEMU can provide a virtual machine with >> various types of virtual SCSI devices. One of those is "scsi-block", >> which is also known as "SCSI passthrough". It means that most of the >> SCSI commands are forwarded transparently from guest device to >> physical host device (/dev/sdi, for example), using the SG_IO ioctl() >> call. Only a few SCSI commands are captured and emulated by QEMU. >> >> This feature is useful e.g. for burning physical optical media, or >> writing physical tapes, from a virtual machine. >> >> - In this scenario, the USB stick that is plugged in the host is >> exposed to the guest with this feature. So, when the >> ScsiDiskInquiryDevice() function runs in the guest (as part of OVMF), >> the INQUIRY command (asking for the Supported VPD Pages" VPD page) is >> forwarded to the USB stick on the host. And that device returns garbage. >> >> - It is important to note that the "garbage" is not inserted by >> either the host kernel's usb-storage driver, or by QEMU. Even without >> virtualization, the host kernel consciously avoids asking SCSI disks >> that are actually backed by USB mass-storage devices for VPD pages, >> because the kernel developers have realized that most (if not all) of >> USB mass-storage devices fail to respond correctly. Please see this >> host kernel commit: >> >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit >> /?id=09b6b51b0b6c >> >> - In <https://bugzilla.redhat.com/show_bug.cgi?id=1330955#c14>, I >> demonstrate what happens when such an INQUIRY is sent manually to the >> SCSI disk that is backed by the USB flash drive. For a genuine SCSI >> disk, the command completes: >> >> # sg_vpd -v /dev/sda >> Supported VPD pages VPD page: >> inquiry cdb: 12 01 00 00 fc 00 >> [PQual=0 Peripheral device type: disk] >> Supported VPD pages [sv] >> Unit serial number [sn] >> Device identification [di] >> ATA information (SAT) [ai] >> Block limits (SBC) [bl] >> Block device characteristics (SBC) [bdc] >> Logical block provisioning (SBC) [lbpv] >> >> Buth the USB flash drive responds with garbage: >> >> # sg_vpd -v /dev/sdi >> Supported VPD pages VPD page: >> inquiry cdb: 12 01 00 00 fc 00 >> invalid VPD response; probably a STANDARD INQUIRY response First 32 >> bytes of bad response >> 00 00 80 06 02 1f 00 00 00 00 00 00 00 00 00 00 00 ................ >> 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >> fetching VPD page failed >> >> - So this patch is motivated by the case when a USB mass-storage >> device is presented as a SCSI disk, directly on the (virtual) >> hardware level, and it provides a bogus 0x00 VPD page. > > I'm no longer certain that edk2's ScsiDiskDxe is the right place to > fix this problem. It seems that the usb-storage driver in Linux could > be the culprit -- it should be watching for INQUIRY commands with EVPD > set, and reject them before forwarding them to the device. That is the > method that complies with both SPC-4 and the UFI command spec. (And, > edk2 handles this case correctly, already.) Please see > <https://bugzilla.redhat.com/show_bug.cgi?id=1330955#c17>. > > So, for the time being, I'm withdrawing this patch. Sigh, scratch that please (and please excuse the noise). It turns out that the USB device in question has: - one configuration - for that configuration, one interface - for that interface, a /bInterfaceSubClass/ value of 6 (implying "SCSI transparent command set") This implies that the USB device in question is supposed to parse and handle *all* valid SCSI commands that are sent to it. Meaning, if the device gets an INQUIRY+EVPD command from ScsiDiskDxe -- transparently forwarded by QEMU and the host Linux kernel --, then the device is responsible for rejecting the command with CHECK CONDITION (if the device doesn't support INQUIRY+EVPD). Instead of this, however, the device silently returns a standard INQUIRY response (rather than a CHECK CONDITION, or even the requested VPD page). Hence, this device is *genuinely* broken. And, I would like to get this patch into ScsiDiskDxe after all. Thank you Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
