qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Alexander Graf <agraf@suse.de>, Paolo Bonzini <pbonzini@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
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	[thread overview]
Message-ID: <525FE7E8.5050902@ozlabs.ru> (raw)
In-Reply-To: <F5F2D1F8-2E53-4E24-87D0-ACC16A36C3A7@suse.de>

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

  reply	other threads:[~2013-10-17 13:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-16  5:04 [Qemu-devel] virtio-blk-pci: how to tell if it is CD or HDD? Alexey Kardashevskiy
2013-10-16  6:36 ` Paolo Bonzini
2013-10-16  7:59   ` Alexey Kardashevskiy
2013-10-17 12:38     ` Alexey Kardashevskiy
2013-10-17 12:54       ` Paolo Bonzini
2013-10-17 13:02         ` Alexander Graf
2013-10-17 13:36           ` Alexey Kardashevskiy [this message]
2013-10-17 13:49             ` Paolo Bonzini
2013-10-17 13:09         ` Alexey Kardashevskiy
2013-10-17 13:48           ` Paolo Bonzini
2013-10-18  4:56           ` Nikunj A Dadhania

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=525FE7E8.5050902@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=agraf@suse.de \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).