All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Subject: Re: [Qemu-devel] ARM cpu object, setting properties from board model
Date: Wed, 20 Nov 2013 16:19:49 +0100	[thread overview]
Message-ID: <528CD315.8070700@suse.de> (raw)
In-Reply-To: <CAFEAcA9jtYusaB1dWt_1T28cJdMDOmL4860iT9C3c7ZSii59=A@mail.gmail.com>

Am 19.11.2013 21:01, schrieb Peter Maydell:
> I find myself with a use case where I would like to set
> a CPU object property from the board model init function
> (specifically, I'd like the board model to be able to say
> "this CPU will boot via PSCI so if you're KVM then start
> it appropriately").
> 
> I could just reach in and fiddle with the ARMCPU field
> the way hw/arm/highback.c does with reset_cbar (and in fact
> that's what I'm likely to do for the moment). However it
> seems like it would be nicer for it to be an official
> QOM property. This is alas not currently possible because
> cpu_arm_init() does both 'init' and 'realize', and once
> you've called it it's too late to set properties.
> 
> Andreas -- did you have any thoughts/plans/code in this area?
> Splitting the realize part out of cpu_arm_init(), or
> providing a cpu_arm_init_dont_realize() [ugh], would be
> easy to code but is it going in the right direction?

My first thought without reviewing the code is to just inline
object_new() followed by object_property_set_bool() in the machine -
that's what I've done for my downstream rl78, where I needed to postpone
realizing the CPU until the firmware blob had been loaded (similar to
armv7m, you may remember pointing me to that example :)).

You are free to split cpu_arm_init() into calling a non-realizing
function, followed by the realization step, then you can reuse that in
multiple places if needed. Mid-term I intend cpu_*_init() to not realize
the CPU - for boards that is waiting on the recursive realization
support, so that only *-user would need to manually realize the CPU.

I would by contrast caution not to blindly use global properties for
cpu_arm_init() since mixed cores are getting more and more common. For
x86 that is much less problematic.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  parent reply	other threads:[~2013-11-20 15:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19 20:01 [Qemu-devel] ARM cpu object, setting properties from board model Peter Maydell
2013-11-19 20:12 ` Peter Maydell
2013-11-19 20:16 ` Igor Mammedov
2013-11-20 15:19 ` Andreas Färber [this message]
2013-11-20 15:36   ` Peter Maydell

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=528CD315.8070700@suse.de \
    --to=afaerber@suse.de \
    --cc=imammedo@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.