qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Anthony Liguori <aliguori@us.ibm.com>,
	qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
	Paul Mackerras <paulus@samba.org>,
	qemu-ppc@nongnu.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH 4/4] xics: Support for in-kernel XICS interrupt controller
Date: Sat, 03 Aug 2013 00:57:20 +1000	[thread overview]
Message-ID: <51FBC8D0.8050603@ozlabs.ru> (raw)
In-Reply-To: <51F9BA0E.6050003@suse.de>

On 08/01/2013 11:29 AM, Andreas Färber wrote:
> Am 01.08.2013 02:14, schrieb Alexey Kardashevskiy:
>> On 08/01/2013 05:52 AM, Andreas Färber wrote:
>>> Am 17.07.2013 08:37, schrieb Alexey Kardashevskiy:

>>>> +
>>>> +    icp->ss = g_malloc0(icp->nr_servers*sizeof(ICPState));
>>>> +    for (i = 0; i < icp->nr_servers; i++) {
>>>> +        char buffer[32];
>>>> +        object_initialize(&icp->ss[i], TYPE_ICP_KVM);
>>>> +        snprintf(buffer, sizeof(buffer), "icp[%d]", i);
>>>> +        object_property_add_child(OBJECT(icp), buffer, OBJECT(&icp->ss[i]), NULL);
>>>> +        qdev_init_nofail(DEVICE(&icp->ss[i]));
>>>
>>> object_property_set_bool()
>>
>>
>> ? Anthony did XICS refactoring recently and that has qdev_init_nofail().
> 
> Nobody is perfect. ;)
> 
> The point is, this is an object, and in realize you shouldn't abort but
> set errp and leave error printing and handling to your caller. The QOM
> API as opposed to qdev works with an Error object that you can
> error_propagate() to your caller.
> 
> (Also using qdev_* for something that is new-style QOM is ugly IMO.)
> 
>>> Where does icp->nr_servers come from?
>>
>> Via properties in try_create_xics() (hw/ppc/spapr.c).
> 
> Sounds tricky... Peter introduced static array properties for a similar
> purpose, I believe. Don't know if that would help here.

Peter who? For what purpose? Could you please point to it? Cannot find it
anywhere.


>>
>>> Is there no way to split this into
>>> instance_init and realize?
>>
>>
>> Why would we want to split?
> 
> Because realize is too late to create new devices: With our targetted
> late, recursive realization model it will not be possible to see and
> modify such objects from management interface - only before realize.


Oh. I lost you here. I need to create XICS with some child ICP devices (now
they are devices). The number of child devices comes from spapr.c via
properties. Now you are saying it is too late to create devices (even so
lame ones) in realize(). So I have to put the creation in instance_init().
Could you please point now I can create device-and-pass-propetries in one
shot? Thanks!


-- 
Alexey

  parent reply	other threads:[~2013-08-02 16:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17  6:37 [Qemu-devel] RFC: [PATCH 0/4] xics: in-kernel support Alexey Kardashevskiy
2013-07-17  6:37 ` [Qemu-devel] [PATCH 1/4] target-ppc: Add helper for KVM_PPC_RTAS_DEFINE_TOKEN Alexey Kardashevskiy
2013-07-17  6:37 ` [Qemu-devel] [PATCH 2/4] xics: add pre_save/post_load/cpu_setup dispatchers Alexey Kardashevskiy
2013-07-17  6:37 ` [Qemu-devel] [PATCH 3/4] xics: rework initialization Alexey Kardashevskiy
2013-07-31 19:22   ` Andreas Färber
2013-07-17  6:37 ` [Qemu-devel] [PATCH 4/4] xics: Support for in-kernel XICS interrupt controller Alexey Kardashevskiy
2013-07-31 18:05   ` Anthony Liguori
2013-07-31 19:52   ` Andreas Färber
2013-07-31 20:47     ` Peter Maydell
2013-08-01  0:14     ` Alexey Kardashevskiy
2013-08-01  1:29       ` Andreas Färber
2013-08-01  2:08         ` Alexey Kardashevskiy
2013-08-01  3:07           ` Andreas Färber
2013-08-01  3:22             ` Alexey Kardashevskiy
2013-08-06 14:14               ` Andreas Färber
2013-08-02 14:57         ` Alexey Kardashevskiy [this message]
2013-08-03  2:45           ` Alexey Kardashevskiy
2013-07-30  2:29 ` [Qemu-devel] RFC: [PATCH 0/4] xics: in-kernel support 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=51FBC8D0.8050603@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=peter.maydell@linaro.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).