From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
Alexander Graf <agraf@suse.de>,
qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
Paul Mackerras <paulus@samba.org>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH 5/6] xics: split to xics and xics-common
Date: Thu, 08 Aug 2013 13:10:03 +1000 [thread overview]
Message-ID: <52030C0B.8020705@ozlabs.ru> (raw)
In-Reply-To: <5202581C.3070700@suse.de>
On 08/08/2013 12:22 AM, Andreas Färber wrote:
> Am 07.08.2013 09:26, schrieb Alexey Kardashevskiy:
>> On 08/07/2013 05:03 PM, Andreas Färber wrote:
>>> Am 07.08.2013 08:06, schrieb Alexey Kardashevskiy:
>>>> [...] How do I test it?
>>>
>>> ./QMP/qom-list to find the path, if not fixed in code yet, and
>>
>> Something is wrong. XICS does not have an id but it should not be a
>> problem, right (btw how to set it from the code?)?
>>
>> [aik@dyn232 ~]$ ./qemu-impreza/QMP/qom-list -s ./qmp-sock
>> /
>
> That's expected for lack of argument.
>
> $ ./QMP/qom-list -s ./qmp-sock /machine
> unattached/
> peripheral/
> peripheral-anon/
> type
>
> This confirms "path ... not fixed in code yet" (otherwise there would've
> been an "spapr/" entry or anything else telling.
>
> So you need to look through /machine/unassigned for the device[n] with
> qom-get /machine/unassigned/device[n].type matching your type, possibly
> device[0] as in my case. From there on you see your icp[0]/ and ics/
> children without searching the unassigned list again.
>
> Or simply use my qom-tree script:
> http://lists.nongnu.org/archive/html/qemu-devel/2013-07/txte1WIbWzu5Z.txt
Yep. That works, thanks.
> Setting a canonical path is done via object_property_add_child() after
> instantiating and before realizing a device.
> For x86 the northbridge is used as name, i.e. "i440fx" for pc and "q35"
> for q35. Suggest to discuss with Anthony how to structure the
> composition tree for sPAPR.
I tried inserting this:
object_property_add_child(qdev_get_machine(), busname, OBJECT(dev), NULL);
in TYPE_SPAPR_PCI_HOST_BRIDGE's spapr_phb_init() (I thought this is what
i440fx_init() does in the very beginning) but when I do that, spapr_phb
already has a parent of a "container" type so assert happens.
What is the aim of all of this? Is it not to have "unattached" in a path
starting with /machine?
btw I have added notes in the previous response against splitting ICS
initialization into 2 functions and you skipped it. Does this mean you do
not want to waste more of your time persuading me and this is the real
stopped or you just gave up? :) Thanks.
--
Alexey
next prev parent reply other threads:[~2013-08-08 3:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-06 8:27 [Qemu-devel] [PATCH 0/6 v2] xics: reworks and in-kernel support Alexey Kardashevskiy
2013-08-06 8:27 ` [Qemu-devel] [PATCH 1/6] target-ppc: Add helper for KVM_PPC_RTAS_DEFINE_TOKEN Alexey Kardashevskiy
2013-08-06 9:11 ` Andreas Färber
2013-08-06 8:27 ` [Qemu-devel] [PATCH 2/6] xics: add pre_save/post_load/cpu_setup dispatchers Alexey Kardashevskiy
2013-08-06 9:19 ` Andreas Färber
2013-08-06 8:27 ` [Qemu-devel] [PATCH 3/6] xics: move registration of global state to realize() Alexey Kardashevskiy
2013-08-06 9:06 ` Andreas Färber
2013-08-06 8:27 ` [Qemu-devel] [PATCH 4/6] xics: minor changes and cleanups Alexey Kardashevskiy
2013-08-06 9:26 ` Andreas Färber
2013-08-06 8:27 ` [Qemu-devel] [PATCH 5/6] xics: split to xics and xics-common Alexey Kardashevskiy
2013-08-06 9:53 ` Andreas Färber
2013-08-07 6:06 ` Alexey Kardashevskiy
2013-08-07 7:03 ` Andreas Färber
2013-08-07 7:26 ` Alexey Kardashevskiy
2013-08-07 14:22 ` Andreas Färber
2013-08-08 3:10 ` Alexey Kardashevskiy [this message]
2013-08-08 11:33 ` Andreas Färber
2013-08-06 8:27 ` [Qemu-devel] [PATCH 6/6] xics-kvm: Support for in-kernel XICS interrupt controller Alexey Kardashevskiy
2013-08-06 10:12 ` Andreas Färber
2013-08-06 12:06 ` Alexey Kardashevskiy
2013-08-06 15:10 ` Andreas Färber
2013-08-07 7:03 ` Alexey Kardashevskiy
2013-08-07 7:08 ` Andreas Färber
2013-08-07 7:31 ` Alexey Kardashevskiy
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=52030C0B.8020705@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=aliguori@us.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=paulus@samba.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@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).