RFE: support USB Attached Storage

[tomty89]

As of 18582 (6263ae9), ovmf does not support booting usb-uas device in qemu. Not with nec-usb-xhci or usb-ehci.

Even seabios supports booting usb-uas with usb-echi (not with nec-usb-xhci though): https://www.coreboot.org/pipermail/seabios/2016-May/010627.html

[lersek]

Please provide a minimal command line that works with SeaBIOS. Thanks.

[tomty89]

qemu-system-x86_64 -drive file=test.img,format=raw,if=none,id=test -device usb-ehci -device usb-uas -device scsi-hd,drive=test -boot menu=on

qemu 2.5.1 and seabios 1.9.2

[lersek]

According to the usb-uas driver in SeaBIOS, a usb-uas device is recognized by: InterfaceSubClass == US_SC_SCSI (numeric value 0x06) and InterfaceProtocol == US_PR_UAS (numeric value 0x62).

In edk2, such constants belong in MdePkg/Include/IndustryStandard/Usb.h. I see USB_MASS_STORE_SCSI with value 0x06 (for the interface subclass) and USB_MASS_STORE_BOT with value 0x50 (for the interface protocol, "Bulk-Only Transport"). No macro is present for interface protocol 0x62 (would be "USB Attached Storage").

Grepping the tree for USB_MASS_STORE_BOT, the MdeModulePkg/Bus/Usb/UsbMassStorageDxe driver matches.

Pairing these findings with the QEMU document docs/usb-storage.txt, I conclude that edk2's USB mass storage driver supports the Bulk Only Transport devices (usb-storage and usb-bot -- according to the QEMU document, the two are indistinguishable within the guest), and that it has no support for USB Attached Storage (device usb-uas).

To verify the Bulk Only Transport case at least, I test-booted a Fedora 23 LiveCD via the usb-storage device, using both nec-usb-xhci and usb-ehci host controllers. Both cases work. (Note that the bootindex=0 property must be added to the usb-storage device, on the QEMU command line.)

Hence, usb-storage works, and usb-uas lacks either a dedicated driver under MdeModulePkg/Bus/Usb/ or support / glue code in MdeModulePkg/Bus/Usb/UsbMassStorageDxe.

If you are okay with using usb-storage, I suggest we close this item.

If you need usb-uas, then this item will have to be retitled, and labeled MdeModulePkg. The MdeModulePkg maintainers might or might not write the patches for you. If you opt for this, please provide your justification / use case for needing usb-uas support in edk2.

You are also welcome to raise the question on edk2-devel -- if you post there, please (a) subscribe at https://lists.01.org/mailman/listinfo/edk2-devel first, and (b) CC the MdeModulePkg maintainers (you can find them in the Maintainers.txt file).

Should we close this bug, or move it to MdeModulePkg?

Thanks.

[tomty89]

Yeah I am aware that it works with usb-storage/usb-bot.

I don't have a strong justification for it. It's just, why not?

Certainly we may not "need" the capability of booting them for a so called "production" VM, since we would probably prefer virtio-scsi or so. However, we may often want to use a VM for testing and simulation. I think that's why qemu is made general by having emulated devices like usb-uas added too (instead of taking approach like the more "production-oriented" Hyper-V in Windows does).

Also, isn't edk2 supposed to be a general implementation of UEFI anyway? So I don't think it's just about qemu + ovmf? I simply see no reason that any UEFI implementation should support booting USB Mass Storage devices but not USB Attached SCSI devices.

[lersek]

I don't have a strong justification for it. It's just, why not?

Are you serious? Each driver in edk2 has to be written first, then maintained going forward, which includes patch reviews and regression testing.

Please refer to #48 to understand my concern better. In that case, we didn't even have to worry about the NVMe driver, since that already existed under MdeModulePkg.

However, we may often want to use a VM for testing and simulation. I think that's why qemu is made general by having emulated devices like usb-uas added too (instead of taking approach like the more "production-oriented" Hyper-V in Windows does).

I can't tell why Gerd added usb-uas to QEMU. FWIW, looking at QEMU commit 0f58f68 (the commit that added the device model), the message says,

usb: add usb attached scsi emulation

$subject says all.  First cut.

It's a pure UAS (usb attached scsi) emulation, without BOT (bulk-only
transport) compatibility.  If your guest can't handle it use usb-storage
instead.

[...]

Doesn't look like a requirement to me.

Also, isn't edk2 supposed to be a general implementation of UEFI anyway? So I don't think it's just about qemu + ovmf?

You are correct, edk2 is the reference PI and UEFI implementation, and OVMF is just one platform.

I simply see no reason that any UEFI implementation should support booting USB Mass Storage devices but not USB Attached SCSI devices.

I agree that supporting USB Attached Storage would fit the profile of edk2. I have no opinion however whether the MdeModulePkg maintainers can justify or not the cost of developing and maintaining such a driver (or adding the necessary code to the existing driver).

But, at this point we can certainly move the feature request to MdeModulePkg. Thanks.

[tomty89]

Thanks for moving it.

FWIW, by "why not" I didn't mean like, anything should be added as long as someone think of it or mention of it, but like, because UAS is not even some platform or vendor specfic thing (like virtio, for example), but a modern/enhanced version of USB mass storage, so I don't know what kind of justification is needed / I should give (or in other word, the justification is that, UAS is yet another de facto standard).

Surely one can argue that, in an emulated environment, we don't have often have a sane reason to have a boot drive emulated as uas device, but since edk2 is not specific to VM/qemu, so the argument is not really relevant here.

I guess the only reason not to add the support, that I can think of after reading your reply, is that it is "safe" (as in, required in UAS spec, or practical in all UAS decives) for UEFI implementations to rely on the BOT part of the device for booting, while the OS support to the UAS part of the device will not be hence changed/affected. In other word, the responsibility is on the qemu side -- to have BOT compatibility added to usb-uas. (However, I don't know if things work in that way.)

[lersek]

@tomty89 thanks for clarifying. I suggest to take this discussion (i.e., "why" vs. "why not") to the edk2-devel list -- the maintainers are really responsive there, and I think they should be able to give you more information. Thanks!