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

[Laszlo Ersek]

On 02/13/19 18:00, Philippe Mathieu-Daudé wrote:
> On 2/13/19 9:37 AM, Laszlo Ersek wrote:
>>
>> 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?

Nothing beyond <https://bugzilla.redhat.com/show_bug.cgi?id=917702>.

>>   -device scsi-hd,drive=disk1,bus=bot1.0,lun=0,bootindex=1 \

[...]

>> 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 :/

OK, that explains the issue in (2). Wrong config. Thanks!

[...]

>> (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:

[...]

>>> 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'?

Thanks, but no, thanks. :)

For USB storage options, I prefer the absolute minimum. I thought that
usb-storage was the end of the story -- it works perfectly fine; please
see the scope in:
- https://bugzilla.redhat.com/show_bug.cgi?id=1458192
- https://github.com/tianocore/edk2/commit/f9c59fa44ae2

Due to <https://bugzilla.redhat.com/show_bug.cgi?id=917702>, usb-bot now
looks relevant as well. I'm trying to see how that maps to the existent
usb-storage support code, and what extensions if any are needed.

"usb-uas" remains totally out of scope though.

--*--

Anyway, now I realize that my test (3) was invalid too, because, by
*changing* lun0 to lun1 (rather than adding lun1 after lun0), I again
created a discontiguous LUN space.

(4) Unfortunately, the same assertion failure hits in edk2, even if I
add *both* lun0 and lun1:

  -drive id=disk1,if=none,format=raw,readonly,file=$APPDISK \
  -drive id=disk2,if=none,format=raw,readonly,file=$APPDISK \
  -device qemu-xhci,id=xhci1,p3=15,addr=02.0 \
  -device usb-bot,bus=xhci1.0,port=4,id=bot1 \
  -device scsi-hd,drive=disk1,bus=bot1.0,lun=0,bootindex=1 \
  -device scsi-hd,drive=disk2,bus=bot1.0,lun=1,bootindex=2 \

Based on the last paragraphs in "docs/usb-storage.txt" (specifically
step (2b)), I'd expect this to work -- do you agree?

Thank you!
Laszlo