qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gerd Hoffmann
Subject: Re: [Qemu-ppc] [PATCH] hw/ppc/spapr: Fix boot path of usb-host storage devices
Date: Tue, 13 Dec 2016 14:52:56 +0100

On Di, 2016-12-13 at 13:44 +0100, Thomas Huth wrote:
> When passing through a USB storage device to a pseries guest, it
> is currently not possible to automatically boot from the device
> if the "bootindex" property has been specified, too (e.g. when using
> "-device nec-usb-xhci -device usb-host,hostbus=1,hostaddr=2,bootindex=0"
> at the command line). The problem is that QEMU builds a device tree path
> like "/address@hidden/address@hidden/address@hidden" and passes it to SLOF
> 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.
> 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.

> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 208ef7b..fe315b5 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2185,6 +2185,15 @@ static char *spapr_get_fw_dev_path(FWPathProvider *p, 
> BusState *bus,
>          }
>      }
>  
> +    if (strcmp("usb-host", qdev_fw_name(dev)) == 0) {
> +        USBDevice *usbdev = CAST(USBDevice, dev, TYPE_USB_DEVICE);
> +
> +        /* SLOF scans USB storage and adds a "disk" node for the SCSI LUN */
> +        if (usb_host_dev_is_scsi_storage(usbdev)) {
> +            return g_strdup_printf("address@hidden/disk", 
> usbdev->port->path);
> +        }
> +    }
> +

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 ...

cheers,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]