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:36:40 +1100
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0

On 10/18/2013 12:02 AM, Alexander Graf wrote:
> 
> On 17.10.2013, at 14:54, Paolo Bonzini <address@hidden> 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.
>>
>>> 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.
> 
> 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



reply via email to

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