Re: [Qemu-devel] [PATCH] hw/ppc/spapr: Fix boot path of usb-host storage devices

[Thomas Huth]

On 14.12.2016 10:36, Gerd Hoffmann wrote:
>   Hi,
> 
>>>> in the /chosen/qemu,boot-list property. SLOF, however, probes the
>>>> USB device, recognizes that it is a storage device and thus changes
>>>> its name to "storage", and additionally adds a child node for the
>>>> SCSI LUN, so the correct boot path in SLOF is something like
>>>> "/address@hidden/address@hidden/address@hidden/address@hidden" instead.
> 
> Sure this is correct?

Yes, this is what SLOF is using / expecting.

> usb-storage (aka virtual usb stick) creates paths like this:
> 
>   
> /address@hidden/address@hidden,2/address@hidden/address@hidden/address@hidden,0
> 
> i.e. there is a extra channel element (probably for host adapters with
> multiple scsi busses).

That's true for the default case, but for the pseries machine, there is
already code that changes the boot path for virtual usb-storage devices,
see the function spapr_get_fw_dev_path() :

        ... else if (usb) {
            /*
             * We use SRP luns of the form 01000000 | (usb-port << 16) | lun
             * in the top 32 bits of the 64-bit LUN
             */
            unsigned usb_port = atoi(usb->port->path);
            unsigned id = 0x1000000 | (usb_port << 16) | d->lun;
            return g_strdup_printf("address@hidden"PRIX64, qdev_fw_name(dev),
                                   (uint64_t)id << 32);
        }

>>>> So when we detect an USB mass storage device with SCSI interface,
>>>> we've got to adjust the firmware boot-device path properly, so that
>>>> SLOF can automatically boot from the device.
> 
>>> Any reason why this is hidden in ppc/spapr?
>>>
>>> usb-host could implement the ->fw_name callback instead to create a name
>>> depending on the device type ...
> 
>> The naming is specific to SLOF ... not sure what happens with other
>> firmware implementations, so spapr.c sounds like the better place to me
>> right now.
> 
> If usb-host (and usb-redir too btw) create paths identical to the ones
> created by usb-storage.  Existing firmware should cope just fine
> (assuming bootindex for usb-storage works).

Which firmware can deal with these original device paths with "address@hidden"
in it? Certainly not SLOF. Maybe OpenBIOS? Does OpenBIOS support USB storage
devices?

 Thomas