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

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

[Alexey Kardashevskiy]

Hi!

Normally on sPAPR platform the IBMVSCSI host bus adapter is used which is
SCSI. So when we want some image to appear as a DVD to the guest
(particularly SLOF - our firmware), we use "-device scsi-cd". Or QEMU
extracts this automatically from the "media=cdrom" property of "-drive"
(correct?). And then the SCSI bus tells the guest what is what. SLOF
firmware uses this to create "disk" and "cdrom" aliases to correcly apply
the boot order. So far so good.

Now we are trying (via libvirt) to add both HDD and DVD as "virtio-blk-pci"
devices:

-drive file=virtimg/rhel6-root.img,if=none,format=raw,\
id=drive-virtio-disk1,cache=none \
-device virtio-blk-pci,bus=pci,addr=0x4,\
drive=drive-virtio-disk1,id=virtio-disk1,bootindex=2 \
\
-drive file=virtimg/SLES-11-SP3-DVD-ppc64-GM-DVD1.iso,\
if=none,media=cdrom,id=drive-virtio-disk2,readonly=on,\
format=raw\
-device virtio-blk-pci,bus=pci,addr=0x5,\
drive=drive-virtio-disk2,id=virtio-disk2,bootindex=1

No SCSI bus is created in this case. Both devices appear to SLOF as HDDs so
it creates just one "disk" alias and no "cdrom" alias and if we are not
lucky and DVD got bigger PCI slot#, we will never be able to boot from DVD.

Is there any way to distinguish HDD from DVD via virtio protocol from the
guest (i.e. SLOF)? Thanks!


-- 
Alexey

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

[Paolo Bonzini]

Il 16/10/2013 07:04, Alexey Kardashevskiy ha scritto:
> Hi!
> 
> Normally on sPAPR platform the IBMVSCSI host bus adapter is used which is
> SCSI. So when we want some image to appear as a DVD to the guest
> (particularly SLOF - our firmware), we use "-device scsi-cd". Or QEMU
> extracts this automatically from the "media=cdrom" property of "-drive"
> (correct?). And then the SCSI bus tells the guest what is what. SLOF
> firmware uses this to create "disk" and "cdrom" aliases to correcly apply
> the boot order. So far so good.
> 
> Now we are trying (via libvirt) to add both HDD and DVD as "virtio-blk-pci"
> devices:
> 
> -drive file=virtimg/rhel6-root.img,if=none,format=raw,\
> id=drive-virtio-disk1,cache=none \
> -device virtio-blk-pci,bus=pci,addr=0x4,\
> drive=drive-virtio-disk1,id=virtio-disk1,bootindex=2 \
> \
> -drive file=virtimg/SLES-11-SP3-DVD-ppc64-GM-DVD1.iso,\
> if=none,media=cdrom,id=drive-virtio-disk2,readonly=on,\
> format=raw\
> -device virtio-blk-pci,bus=pci,addr=0x5,\
> drive=drive-virtio-disk2,id=virtio-disk2,bootindex=1
> 
> No SCSI bus is created in this case. Both devices appear to SLOF as HDDs so
> it creates just one "disk" alias and no "cdrom" alias and if we are not
> lucky and DVD got bigger PCI slot#, we will never be able to boot from DVD.
> 
> Is there any way to distinguish HDD from DVD via virtio protocol from the
> guest (i.e. SLOF)? Thanks!

No, virtio-blk is always a HDD.

Does bootindex work with pSeries?

Paolo

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

[Alexey Kardashevskiy]

On 10/16/2013 05:36 PM, Paolo Bonzini wrote:
> Il 16/10/2013 07:04, Alexey Kardashevskiy ha scritto:
>> Hi!
>>
>> Normally on sPAPR platform the IBMVSCSI host bus adapter is used which is
>> SCSI. So when we want some image to appear as a DVD to the guest
>> (particularly SLOF - our firmware), we use "-device scsi-cd". Or QEMU
>> extracts this automatically from the "media=cdrom" property of "-drive"
>> (correct?). And then the SCSI bus tells the guest what is what. SLOF
>> firmware uses this to create "disk" and "cdrom" aliases to correcly apply
>> the boot order. So far so good.
>>
>> Now we are trying (via libvirt) to add both HDD and DVD as "virtio-blk-pci"
>> devices:
>>
>> -drive file=virtimg/rhel6-root.img,if=none,format=raw,\
>> id=drive-virtio-disk1,cache=none \
>> -device virtio-blk-pci,bus=pci,addr=0x4,\
>> drive=drive-virtio-disk1,id=virtio-disk1,bootindex=2 \
>> \
>> -drive file=virtimg/SLES-11-SP3-DVD-ppc64-GM-DVD1.iso,\
>> if=none,media=cdrom,id=drive-virtio-disk2,readonly=on,\
>> format=raw\
>> -device virtio-blk-pci,bus=pci,addr=0x5,\
>> drive=drive-virtio-disk2,id=virtio-disk2,bootindex=1
>>
>> No SCSI bus is created in this case. Both devices appear to SLOF as HDDs so
>> it creates just one "disk" alias and no "cdrom" alias and if we are not
>> lucky and DVD got bigger PCI slot#, we will never be able to boot from DVD.
>>
>> Is there any way to distinguish HDD from DVD via virtio protocol from the
>> guest (i.e. SLOF)? Thanks!
> 
> No, virtio-blk is always a HDD.

Thanks, good to know.

> Does bootindex work with pSeries?

Nope. Seems the time to support this has come :)



> 
> Paolo
> 


-- 
Alexey

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

[Alexey Kardashevskiy]

On 10/16/2013 06:59 PM, Alexey Kardashevskiy wrote:
> On 10/16/2013 05:36 PM, Paolo Bonzini wrote:
>> Il 16/10/2013 07:04, Alexey Kardashevskiy ha scritto:
>>> Hi!
>>>
>>> Normally on sPAPR platform the IBMVSCSI host bus adapter is used which is
>>> SCSI. So when we want some image to appear as a DVD to the guest
>>> (particularly SLOF - our firmware), we use "-device scsi-cd". Or QEMU
>>> extracts this automatically from the "media=cdrom" property of "-drive"
>>> (correct?). And then the SCSI bus tells the guest what is what. SLOF
>>> firmware uses this to create "disk" and "cdrom" aliases to correcly apply
>>> the boot order. So far so good.
>>>
>>> Now we are trying (via libvirt) to add both HDD and DVD as "virtio-blk-pci"
>>> devices:
>>>
>>> -drive file=virtimg/rhel6-root.img,if=none,format=raw,\
>>> id=drive-virtio-disk1,cache=none \
>>> -device virtio-blk-pci,bus=pci,addr=0x4,\
>>> drive=drive-virtio-disk1,id=virtio-disk1,bootindex=2 \
>>> \
>>> -drive file=virtimg/SLES-11-SP3-DVD-ppc64-GM-DVD1.iso,\
>>> if=none,media=cdrom,id=drive-virtio-disk2,readonly=on,\
>>> format=raw\
>>> -device virtio-blk-pci,bus=pci,addr=0x5,\
>>> drive=drive-virtio-disk2,id=virtio-disk2,bootindex=1
>>>
>>> No SCSI bus is created in this case. Both devices appear to SLOF as HDDs so
>>> it creates just one "disk" alias and no "cdrom" alias and if we are not
>>> lucky and DVD got bigger PCI slot#, we will never be able to boot from DVD.
>>>
>>> Is there any way to distinguish HDD from DVD via virtio protocol from the
>>> guest (i.e. SLOF)? Thanks!
>>
>> No, virtio-blk is always a HDD.
> 
> Thanks, good to know.
> 
>> Does bootindex work with pSeries?
> 
> Nope. Seems the time to support this has come :)

I need some help to understand how to do that properly. There are 2 sets of
callbacks - get_dev_path() and get_fw_dev_path(). And we also have
device-tree which SLOF parses and creates aliases from so it is a good hint
what SLOF can boot from.


So I added some debug output and run a test. The parameters below create
virtio-scsi bus with 2 DVDs, ibmvscsi bus with 2 DVDs (same ones but this
is not the point), virtio-net-pci.


 -device virtio-scsi-pci,id=v11 \
 -drive file=virtimg/SLES-11-SP3-DVD-ppc64-GM-DVD1.iso,if=none,id=vi11,\
readonly=on,format=raw \
 -device scsi-cd,bus=v11.0,channel=0,scsi-id=3,lun=1,\
drive=vi11,bootindex=13 \
 -drive file=virtimg/Fedora-18-ppc64-DVD.iso,if=none,id=vi12,\
readonly=on,format=raw \
 -device scsi-cd,bus=v11.0,channel=0,scsi-id=3,lun=2,\
drive=vi12,bootindex=12 \
 -netdev tap,id=netdev5000,ifname=tap5000,script=ifup.sh,\
downscript=ifdown.sh \
 -device virtio-net-pci,netdev=netdev5000,bus=pci,addr=1.0,\
mac=C0:41:49:4b:00:00,bootindex=11 \
 -device spapr-vscsi,id=s11 \
 -drive file=virtimg/SLES-11-SP3-DVD-ppc64-GM-DVD1.iso,if=none,id=i11,\
readonly=on,format=raw \
 -device scsi-cd,bus=s11.0,channel=0,scsi-id=3,lun=1,\
drive=i11,bootindex=3 \
 -drive file=virtimg/Fedora-18-ppc64-DVD.iso,if=none,id=i12,\
readonly=on,format=raw \
 -device scsi-cd,bus=s11.0,channel=0,scsi-id=3,lun=2,\
drive=i12,bootindex=2 \


I did few changes in QEMU (diffs are below) to replace default
"/spapr-pci-host-bridge/" with "/pci@800000020000000/" in what
qdev_get_dev_path/qdev_get_fw_dev_path return, this is to distinguish PHBs.

I added some printfs to see what qdev_*dev_path() do:

qdev_get_dev_path:
v-scsi@71000001/0:3:2 suffix=(null)
v-scsi@71000001/0:3:1 suffix=(null)
pci@800000020000000:01.0 suffix=/ethernet-phy@0
pci@800000020000000:00.0/0:3:2 suffix=(null)
pci@800000020000000:00.0/0:3:1 suffix=(null)

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)
/pci@800000020000000/ethernet@1 suffix=/ethernet-phy@0
/pci@800000020000000/scsi@0/channel@0/disk@3,2 suffix=(null)
/pci@800000020000000/scsi@0/channel@0/disk@3,1 suffix=(null)

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!


btw what format does qdev_get_fw_dev_path() use? This is not OF1275 so what
is it?




diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index b84cd4a..232ed2c 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -224,6 +224,10 @@ static char *sysbus_get_fw_dev_path(DeviceState *dev)
     char path[40];
     int off;

+    if (dev->id) {
+        return g_strdup(dev->id);
+    }
+
     off = snprintf(path, sizeof(path), "%s", qdev_fw_name(dev));

     if (s->num_mmio) {


diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index 8c75adb..d55177e 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -604,6 +604,10 @@ static void spapr_phb_realize(DeviceState *dev, Error
**errp)
     } else {
         busname = sphb->dtbusname;
     }
+    if (!dev->id) {
+        dev->id = g_strdup(sphb->dtbusname);
+    }
+
     bus = pci_register_bus(dev, busname,
                            pci_spapr_set_irq, pci_spapr_map_irq, sphb,
                            &sphb->memspace, &sphb->iospace,





-- 
Alexey

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

[Paolo Bonzini]

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

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

[Alexander Graf]

On 17.10.2013, at 14:54, Paolo Bonzini <pbonzini@redhat.com> 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.
> 
>> 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.

But please make sure to not block the path for non-SLOF machines. -M mac99 should still be able to get different path names for PCI devices for example.


Alex

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

[Alexey Kardashevskiy]

On 10/18/2013 12:02 AM, Alexander Graf wrote:
> 
> On 17.10.2013, at 14:54, Paolo Bonzini <pbonzini@redhat.com> 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.
>>
>>> 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.
> 
> But please make sure to not block the path for non-SLOF machines. -M mac99 should still be able to get different path names for PCI devices for example.

Ok. Then question for you. I need to change root PHB name from
spapr-pci-host-bridge (which is a class name) to something reasonable. For
example, PCIHostBridgeClass::root_bus_path does the job.

But this part of OF path is made by sysbus_get_fw_dev_path() from
hw/core/sysbus.c which does not know about PCI. So it cannot call PCI
callbacks.

I workarounded this by setting PHB's "id" to what sysbus_get_fw_dev_path()
returns but this is barely the proper fix.

I could initialize my PHBs s->mmio[0].addr to BUID and
sysbus_get_fw_dev_path() would return what I need but it won't be MMIO by
any mean and I do not really want to be responsible for all side effect it
may have :)

So how to fix it correctly? Thanks.


-- 
Alexey

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

[Paolo Bonzini]

Il 17/10/2013 15:36, Alexey Kardashevskiy ha scritto:
>> > But please make sure to not block the path for non-SLOF machines. -M mac99 should still be able to get different path names for PCI devices for example.
> Ok. Then question for you. I need to change root PHB name from
> spapr-pci-host-bridge (which is a class name) to something reasonable. For
> example, PCIHostBridgeClass::root_bus_path does the job.
> 
> But this part of OF path is made by sysbus_get_fw_dev_path() from
> hw/core/sysbus.c which does not know about PCI. So it cannot call PCI
> callbacks.
> 
> I workarounded this by setting PHB's "id" to what sysbus_get_fw_dev_path()
> returns but this is barely the proper fix.
> 
> I could initialize my PHBs s->mmio[0].addr to BUID and
> sysbus_get_fw_dev_path() would return what I need but it won't be MMIO by
> any mean and I do not really want to be responsible for all side effect it
> may have :)
> 
> So how to fix it correctly?

Set dc->fw_name for the spapr-pci-host-bridge class, and similarly for
the vio bridge.

Paolo

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

[Alexey Kardashevskiy]

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

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

[Paolo Bonzini]

Il 17/10/2013 15:09, Alexey Kardashevskiy ha scritto:
>> 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

Yes, I was referring more to the vio cases.

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

No, a machine callback that will recognize SCSI disks and return
disk@8302000000000000.  This will replace the "channel@0/disk@3,2" path
returned by default.

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

It's made up.

Paolo

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

[Nikunj A Dadhania]

Alexey Kardashevskiy <aik@ozlabs.ru> writes:

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

That is constructed in SLOF/board-qemu/slof/vio-vscsi.fs:

\ We use SRP luns of the form 8000 | (bus << 8) | (id << 5) | lun
\ in the top 16 bits of the 64-bit LUN

bus is target here. I guess that could be handled in Qemu, and both need
to be in sync.

Regards
Nikunj