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
