Re: [Qemu-devel] [edk2] nonzero LUN on USB Bulk Only Transfer fails with QEMU+edk2

[Philippe Mathieu-Daudé]

Hi Laszlo,

On 2/13/19 9:37 AM, Laszlo Ersek wrote:
> Hi,
> 
> using QEMU, when I specify a nonzero LUN for the hard disk that sits on
> the "SCSI bus" that embodies the USB Bulk Only Transfer device, then
> UsbMassStorageDxe fails to recognize the hard disk.
> 
> (1) Consider the following QEMU command line snippet:
> 
>   -drive id=disk1,if=none,format=raw,readonly,file=$APPDISK \
>   -device qemu-xhci,id=xhci1,p3=15,addr=02.0 \
>   -device usb-bot,bus=xhci1.0,port=3,id=bot1 \

Do you have a specific need to use the 'usb-bot' device?

>   -device scsi-hd,drive=disk1,bus=bot1.0,lun=0,bootindex=1 \
> 
> For this (i.e., lun=0), I see the following INQUIRY exchange between
> UsbMassStorageDxe and QEMU:
> 
>> Lun=0 InquiryCmd {
>> Lun=0 InquiryCmd 000000 12 00 00 00 24 00 00 00 00 00 00 00
>> Lun=0 InquiryCmd }
>> Lun=0 InquiryData {
>> Lun=0 InquiryData 000000 00 00 05 12 1F 00 00 10 51 45 4D 55 20 20 20 20
>> Lun=0 InquiryData 000010 51 45 4D 55 20 48 41 52 44 44 49 53 4B 20 20 20
>> Lun=0 InquiryData 000020 32 2E 35 2B
>> Lun=0 InquiryData }
> 
> The vendor and product ID fields translate to "QEMU____" and
> "QEMU_HARDDISK___", respectively. (For easier reading, I replaced the
> space characters with underscores, for the sake of better
> readability/wrapping.)
> 
> In this case, edk2 recognizes the disk and things work fine.
> 
> (In fact, for lun=0, the QemuBootOrderLib pattern matching / translation
> works fine as well -- verifying which was my original goal, before I ran
> into the issues below, for nonzero LUNs. But, I digress.)
> 
> 
> (2) If I change the cmdline to "lun=5", then the exchange is:

>From qemu/docs/usb-storage.txt:

  The LUN numbers must be continuous, i.e. for three devices you must
  use 0+1+2. The 0+1+5 numbering from the "usb-uas" example isn't going
  to work with "usb-bot".

A failure is expected :/

> 
>> Lun=0 InquiryCmd {
>> Lun=0 InquiryCmd 000000 12 00 00 00 24 00 00 00 00 00 00 00
>> Lun=0 InquiryCmd }
>> Lun=0 InquiryData {
>> Lun=0 InquiryData 000000 3F 00 05 12 1F 00 00 10 51 45 4D 55 20 20 20 20
>> Lun=0 InquiryData 000010 51 45 4D 55 20 54 41 52 47 45 54 20 20 20 20 20
>> Lun=0 InquiryData 000020 32 2E 35 00
>> Lun=0 InquiryData }
> 
> Here the product ID is unchanged, but the vendor ID becomes
> "QEMU_TARGET_____".
> 
> And, edk2 fails to recognize the device:
> 
>> UsbBootGetParams: Found an unsupported peripheral type[31]
>> UsbMassInitMedia: UsbBootGetParams (Unsupported)
>> UsbMassInitNonLun: UsbMassInitMedia (Unsupported)
>> USBMassDriverBindingStart: UsbMassInitNonLun (Unsupported)
> 
> This happens because the first byte in the response is 0x3F. QEMU sets
> this byte in
> 
>>         r->buf[0] = TYPE_NOT_PRESENT | TYPE_INACTIVE;
> 
> in function scsi_target_emulate_inquiry(), file "hw/scsi/scsi-bus.c".
> 
> And edk2 parses the byte in UsbBootInquiry() and UsbBootGetParams()
> (file "MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c"):
> 
>> typedef struct {
>>   UINT8             Pdt;            ///< Peripheral Device Type (low 5 bits)
>>   UINT8             Removable;      ///< Removable Media (highest bit)
>>   UINT8             Reserved0[2];
>>   UINT8             AddLen;         ///< Additional length
>>   UINT8             Reserved1[3];
>>   UINT8             VendorID[8];
>>   UINT8             ProductID[16];
>>   UINT8             ProductRevision[4];
>> } USB_BOOT_INQUIRY_DATA;
> 
>> #define USB_BOOT_PDT(Pdt)           ((Pdt) & 0x1f)
> 
>>   UsbMass->Pdt          = (UINT8) (USB_BOOT_PDT (UsbMass->InquiryData.Pdt));
> 
>>   //
>>   // According to USB Mass Storage Specification for Bootability, only 
>> following
>>   // 4 Peripheral Device Types are in spec.
>>   //
>>   if ((UsbMass->Pdt != USB_PDT_DIRECT_ACCESS) &&
>>        (UsbMass->Pdt != USB_PDT_CDROM) &&
>>        (UsbMass->Pdt != USB_PDT_OPTICAL) &&
>>        (UsbMass->Pdt != USB_PDT_SIMPLE_DIRECT)) {
>>     DEBUG ((EFI_D_ERROR, "UsbBootGetParams: Found an unsupported peripheral 
>> type[%d]\n", UsbMass->Pdt));
>>     return EFI_UNSUPPORTED;
>>   }
> 
> It looks likely that at least one of edk2 and QEMU has a bug. Which one
> is it?

Both implementation looks correct at first glance, QEMU replies a
standard SCSI INQUIRY format, while EDK2 expects a "USB Mass Storage
Specification
 for Bootability, Revision 1.0" INQUIRY format.

> Or is the command line incorrect perhaps? (I.e., is it invalid to
> specify *only* lun=5? Does the LUN space have to be contiguous?)
> 
> 
> (3) Starting again from the original command line, if I change "lun=0"
> to "lun=1" (rather than to "lun=5"), then OVMF even hangs, with the
> following log:
> 
>> UsbMassInitMultiLun: Start to initialize No.0 logic unit
>> Lun=0 InquiryCmd {
>> Lun=0 InquiryCmd 000000 12 00 00 00 24 00 00 00 00 00 00 00
>> Lun=0 InquiryCmd }
>> Lun=0 InquiryData {
>> Lun=0 InquiryData 000000 3F 00 05 12 1F 00 00 10 51 45 4D 55 20 20 20 20
>> Lun=0 InquiryData 000010 51 45 4D 55 20 54 41 52 47 45 54 20 20 20 20 20
>> Lun=0 InquiryData 000020 32 2E 35 00
>> Lun=0 InquiryData }
>> UsbBootGetParams: Found an unsupported peripheral type[31]
>> UsbMassInitMedia: UsbBootGetParams (Unsupported)
>> UsbMassInitMultiLun: UsbMassInitMedia (Unsupported)
>> UsbMassInitMultiLun: Start to initialize No.1 logic unit
>> Lun=32 InquiryCmd {
>> Lun=32 InquiryCmd 000000 12 20 00 00 24 00 00 00 00 00 00 00
>> Lun=32 InquiryCmd }
>> Lun=32 InquiryData {
>> Lun=32 InquiryData 000000 00 00 05 12 1F 00 00 10 51 45 4D 55 20 20 20 20
>> Lun=32 InquiryData 000010 51 45 4D 55 20 48 41 52 44 44 49 53 4B 20 20 20
>> Lun=32 InquiryData 000020 32 2E 35 2B
>> Lun=32 InquiryData }
>> UsbBootExecCmd: Success to Exec 0x0 Cmd (Result = 1)
>> UsbBootRequestSense: (Invalid Parameter) with error code (70) sense key 
>> 5/25/0
>> UsbMassInitMedia: UsbBootGetParams (Media changed)
>> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 3DC7DD98
>> InstallProtocolInterface: 964E5B21-6459-11D2-8E39-00A0C969723B 3DBFA6B8
>> InstallProtocolInterface: D432A67F-14DC-484B-B3BB-3F0291849327 3DBFA730
>> UsbMassInitMultiLun: Success to initialize No.1 logic unit
>> InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B 3DBFA2A0
>>  BlockSize : 512
>>  LastBlock : 136B
>> UsbBootExecCmd: Success to Exec 0x28 Cmd (Result = 1)
>> UsbBootRequestSense: (Invalid Parameter) with error code (70) sense key 
>> 5/25/0
>> UsbBootExecCmd: Success to Exec 0x28 Cmd (Result = 1)
>> UsbBootRequestSense: (Invalid Parameter) with error code (70) sense key 
>> 5/25/0
>> UsbBootExecCmd: Success to Exec 0x28 Cmd (Result = 1)
>> UsbBootRequestSense: (Invalid Parameter) with error code (70) sense key 
>> 5/25/0
>> UsbBootExecCmd: Success to Exec 0x28 Cmd (Result = 1)
>> UsbBootRequestSense: (Invalid Parameter) with error code (70) sense key 
>> 5/25/0
>> UsbBootExecCmd: Success to Exec 0x28 Cmd (Result = 1)
>> UsbBootRequestSense: (Invalid Parameter) with error code (70) sense key 
>> 5/25/0
>> UsbBootExecCmd: Success to Exec 0x28 Cmd (Result = 1)
>> UsbBootRequestSense: (Invalid Parameter) with error code (70) sense key 
>> 5/25/0
>> UsbMassReadBlocks: UsbBootReadBlocks (Invalid Parameter) -> Reset
>> XhcUsbPortReset!
>> XhcSetRootHubPortFeature: status Success
>> XhcClearRootHubPortFeature: status Success
>> XhcClearRootHubPortFeature: status Success
>> Disable device slot 1!
>> Enable Slot Successfully, The Slot ID = 0x1
>>     Address 1 assigned successfully
>> UsbIoPortReset: device is now ADDRESSED at 1
>> ASSERT MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c(1915): TrsRing != ((void *) 
>> 0)
> 
> In this case, edk2 seems to recognize that a nonzero LUN is available on
> the target, but the initialization never completes, and then an
> assertion fails, apparently in the lower-level XHCI transport code.

Can you try using the 'usb-uas' device instead of the 'usb-bot'?

> 
> The information that I'm primarily looking for here is which bug tracker
> I should file these under, the edk2 bugzilla, or the QEMU launchpad.
> 
> Thanks,
> Laszlo