From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 41F56202E53BC for ; Wed, 13 Feb 2019 00:38:05 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F2966C049E22; Wed, 13 Feb 2019 08:38:04 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-136.rdu2.redhat.com [10.10.120.136]) by smtp.corp.redhat.com (Postfix) with ESMTP id B8BEB19C7B; Wed, 13 Feb 2019 08:38:00 +0000 (UTC) To: Gerd Hoffmann , Ray Ni Cc: qemu devel list , edk2-devel-01 , Markus Armbruster From: Laszlo Ersek Message-ID: Date: Wed, 13 Feb 2019 09:37:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 13 Feb 2019 08:38:05 +0000 (UTC) Subject: nonzero LUN on USB Bulk Only Transfer fails with QEMU+edk2 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 08:38:06 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 \ -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: > 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? 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. 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