Re: [Qemu-devel] virtio-blk-pci: how to tell if it is CD or HDD?

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 10/17/2013 11:54 PM, Paolo Bonzini wrote:
> Il 17/10/2013 14:38, Alexey Kardashevskiy ha scritto:
>> qdev_get_fw_dev_path:
>> /spapr-vio-bridge/spapr-vscsi/channel@0/disk@3,2 suffix=(null)
>> /spapr-vio-bridge/spapr-vscsi/channel@0/disk@3,1 suffix=(null)
> 
> You need to implement qdev_fw_get_path to change
> 
>  spapr-vio-bridge -> vdevice
>  spapr-vscsi -> v-scsi@REG
>
>> /pci@800000020000000/ethernet@1 suffix=/ethernet-phy@0
> 
> The extra suffix is not a problem since you can parse a prefix successfully.
> 
>> /pci@800000020000000/scsi@0/channel@0/disk@3,2 suffix=(null)
>> /pci@800000020000000/scsi@0/channel@0/disk@3,1 suffix=(null)
> 
> I guess this is virtio-scsi.

Correct.


>> SLOF:
>> 0 > devalias
>> cdrom123 : /pci@800000020000000/scsi@0/disk@103000100000000
>> cdrom12 : /pci@800000020000000/scsi@0/disk@103000200000000
>> hvterm : /vdevice/vty@71000100
>> net : /pci@800000020000000/ethernet@1
>> scsi : /vdevice/v-scsi@71000001
>> cdrom1 : /vdevice/v-scsi@71000001/disk@8301000000000000
>> cdrom : /vdevice/v-scsi@71000001/disk@8302000000000000
>> nvram : /vdevice/nvram@71000000 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/v-scsi@71000001/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.


"channel@0" -> ""? This is a generic scsi bus, cannot change this.
"disk@3,2" -> "disk@8302000000000000"? This is a generic scsi-cd, cannot
change this either


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


A single machine callback which will recognize all possible bootable
devices and replace things like "disk@3,2" -> "disk@8302000000000000"? Hm.

I mean I can do all of that but is it still kosher? :) Or I am missing the
point, again.


>> 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
> "disk@TARGET,LUN" but that does not include the channel.

I am confused now. What standard/format/spec defines this "channel@" thingy
or it is made up by QEMU and the x86 bios shipped with QEMU? "open
firmware" == IEEE1275, right?


-- 
Alexey