qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexey Kardashevskiy
Subject: Re: [Qemu-devel] virtio-blk-pci: how to tell if it is CD or HDD?
Date: Fri, 18 Oct 2013 00:09:42 +1100
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0

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/address@hidden/address@hidden,2 suffix=(null)
>> /spapr-vio-bridge/spapr-vscsi/address@hidden/address@hidden,1 suffix=(null)
> 
> You need to implement qdev_fw_get_path to change
> 
>  spapr-vio-bridge -> vdevice
>  spapr-vscsi -> address@hidden
>
>> /address@hidden/address@hidden suffix=/address@hidden
> 
> The extra suffix is not a problem since you can parse a prefix successfully.
> 
>> /address@hidden/address@hidden/address@hidden/address@hidden,2 suffix=(null)
>> /address@hidden/address@hidden/address@hidden/address@hidden,1 suffix=(null)
> 
> I guess this is virtio-scsi.

Correct.


>> SLOF:
>> 0 > devalias
>> cdrom123 : /address@hidden/address@hidden/address@hidden
>> cdrom12 : /address@hidden/address@hidden/address@hidden
>> hvterm : /vdevice/address@hidden
>> net : /address@hidden/address@hidden
>> scsi : /vdevice/address@hidden
>> cdrom1 : /vdevice/address@hidden/address@hidden
>> cdrom : /vdevice/address@hidden/address@hidden
>> nvram : /vdevice/address@hidden 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/address@hidden/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.


"address@hidden" -> ""? This is a generic scsi bus, cannot change this.
"address@hidden,2" -> "address@hidden"? 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 "address@hidden,2" -> "address@hidden"? 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
> "address@hidden,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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]