From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.85.221.46; helo=mail-wr1-f46.google.com; envelope-from=philmd@redhat.com; receiver=edk2-devel@lists.01.org Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 36D5D201B0445 for ; Wed, 13 Feb 2019 09:00:35 -0800 (PST) Received: by mail-wr1-f46.google.com with SMTP id c8so3356219wrs.4 for ; Wed, 13 Feb 2019 09:00:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y/Tu2MTfAlODVXSLAjEalcqCsHlCeMpVtbBYjC/LnQk=; b=FlPF6M+5QyRY+YNPnqxkW9O4U6rtdX8O9phSn1ZTMLdqVVIz+HoUbas7n0WsMxfBT4 aLFm8J9zC0kc8vjkqsHXn5hH2I0CtS+OHAGoOl37BA5ogBwqeMEbjMzd9c+dPmrKaioC XZUBUS5wgnbtHTnyOZzCMZt34KIOuff/7HqpiWdcBzlOcsm6/BvtzJ2DNgqxrUCY6KD4 sstPKNNLmQuFrV5O6tQMZZF47nvJ8DHaJB7nu+kR6HBQPM00rF7WBBinPvpzs9dPBGsk JG6eMYZbiWMEkRFHA6dVANc/ddzjR8DMfvmmSGRcCI5g1NSAA9R9B3QktQr+YIuucsfH vIMA== X-Gm-Message-State: AHQUAuaXdAvbP6zlUZ3gC/P5QkqFX/D0qDHv+VGEcMHK/9kSL3Wn4Hf9 5WPIz+LgdJwXLKwQQWoeBygC3w== X-Google-Smtp-Source: AHgI3IY7thDjJzG/BsMUxmtm9/0J1p03edK3Ydfj7jGFW7lfoJh996rhvBwYx+Da8We88JGr/WvimQ== X-Received: by 2002:adf:91a7:: with SMTP id 36mr1127653wri.77.1550077233526; Wed, 13 Feb 2019 09:00:33 -0800 (PST) Received: from [192.168.1.103] (10.red-83-35-153.dynamicip.rima-tde.net. [83.35.153.10]) by smtp.gmail.com with ESMTPSA id t5sm4754743wmg.43.2019.02.13.09.00.32 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 09:00:32 -0800 (PST) To: Laszlo Ersek , Gerd Hoffmann , Ray Ni Cc: edk2-devel-01 , qemu devel list , Markus Armbruster References: From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Openpgp: id=89C1E78F601EE86C867495CBA2A3FD6EDEADC0DE; url=http://pgp.mit.edu/pks/lookup?op=get&search=0xA2A3FD6EDEADC0DE Message-ID: <49268e92-0abf-a2d3-a523-2c14e009e9cd@redhat.com> Date: Wed, 13 Feb 2019 18:00:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Subject: Re: 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 17:00:36 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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