From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWn6B-0002qE-64 for qemu-devel@nongnu.org; Thu, 17 Oct 2013 08:54:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VWn64-0005XK-Bn for qemu-devel@nongnu.org; Thu, 17 Oct 2013 08:54:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWn64-0005XG-3R for qemu-devel@nongnu.org; Thu, 17 Oct 2013 08:54:36 -0400 Message-ID: <525FDE06.1000609@redhat.com> Date: Thu, 17 Oct 2013 14:54:30 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <525E1E5C.4090002@ozlabs.ru> <525E33DA.8040106@redhat.com> <525E4759.10402@ozlabs.ru> <525FDA47.9050306@ozlabs.ru> In-Reply-To: <525FDA47.9050306@ozlabs.ru> 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: Alexey Kardashevskiy Cc: "qemu-devel@nongnu.org" , Nikunj A Dadhania , Alex Graf 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. > 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. 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 "disk@TARGET,LUN" but that does not include the channel. Paolo