[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] virtio-blk-pci: how to tell if it is CD or HDD?
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] virtio-blk-pci: how to tell if it is CD or HDD? |
Date: |
Thu, 17 Oct 2013 14:54:30 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9 |
Il 17/10/2013 14:38, Alexey Kardashevskiy ha scritto:
> qdev_get_fw_dev_path:
> /spapr-vio-bridge/spapr-vscsi/address@hidden/address@hidden,2 suffix=(null)
> /spapr-vio-bridge/spapr-vscsi/address@hidden/address@hidden,1 suffix=(null)
You need to implement qdev_fw_get_path to change
spapr-vio-bridge -> vdevice
spapr-vscsi -> address@hidden
> /address@hidden/address@hidden suffix=/address@hidden
The extra suffix is not a problem since you can parse a prefix successfully.
> /address@hidden/address@hidden/address@hidden/address@hidden,2 suffix=(null)
> /address@hidden/address@hidden/address@hidden/address@hidden,1 suffix=(null)
I guess this is virtio-scsi.
> SLOF:
> 0 > devalias
> cdrom123 : /address@hidden/address@hidden/address@hidden
> cdrom12 : /address@hidden/address@hidden/address@hidden
> hvterm : /vdevice/address@hidden
> net : /address@hidden/address@hidden
> scsi : /vdevice/address@hidden
> cdrom1 : /vdevice/address@hidden/address@hidden
> cdrom : /vdevice/address@hidden/address@hidden
> nvram : /vdevice/address@hidden ok
>
>
> In ideal world I would want to get in QEMU what SLOF can understand and
> pass this to SLOF. But QEMU APIs return something which cannot be converted
> straight away.
>
> Or I could simply put bootindex to the device tree nodes (as
> "qemu,bootindex") but in this case "wildcard" nodes support fails as there
> is just a single node "/vdevice/address@hidden/disk" in the device tree
> for all LUNs. And we definitely do not want to create nodes for all disk
> devices.
>
> Or I can implement a "smart" converter from QEMU strings to OF pathnames.
>
> Or I can implement third set of callbacks, something like qdev_OF_dev_path().
>
> Or not support "bootindex" at all.
>
> All possibilities suck but which one sucks less? :) Thanks!
In general, try to make QEMU produce SLOF APIs by modifying the devices
that instantiate the buses.
On top of this, fix the remaining QEMU->OF differences using a callback
in QEMUMachine. This callback would be called by
qdev_get_fw_dev_path_helper and, if it returns something non-NULL, the
result would be used instead of calling bus_get_fw_dev_path.
> btw what format does qdev_get_fw_dev_path() use? This is not OF1275 so what
> is it?
It is based on open-firmware. For SCSI however openfirmware had
"address@hidden,LUN" but that does not include the channel.
Paolo