From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWnKu-00020S-K4 for qemu-devel@nongnu.org; Thu, 17 Oct 2013 09:10:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VWnKn-0002dM-4w for qemu-devel@nongnu.org; Thu, 17 Oct 2013 09:09:56 -0400 Received: from mail-pd0-f175.google.com ([209.85.192.175]:65033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWnKm-0002d4-Ud for qemu-devel@nongnu.org; Thu, 17 Oct 2013 09:09:49 -0400 Received: by mail-pd0-f175.google.com with SMTP id g10so2148111pdj.6 for ; Thu, 17 Oct 2013 06:09:48 -0700 (PDT) Message-ID: <525FE196.4060908@ozlabs.ru> Date: Fri, 18 Oct 2013 00:09:42 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <525E1E5C.4090002@ozlabs.ru> <525E33DA.8040106@redhat.com> <525E4759.10402@ozlabs.ru> <525FDA47.9050306@ozlabs.ru> <525FDE06.1000609@redhat.com> In-Reply-To: <525FDE06.1000609@redhat.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] virtio-blk-pci: how to tell if it is CD or HDD? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "qemu-devel@nongnu.org" , Nikunj A Dadhania , Alex Graf 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