qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org
Cc: Igor Mammedov <imammedo@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [PATCH qom-cpu 0/6] cpu: Unifying features parsing
Date: Sun, 09 Mar 2014 17:11:17 +0100	[thread overview]
Message-ID: <531C92A5.1080604@suse.de> (raw)
In-Reply-To: <53170A15.4060902@ozlabs.ru>

Am 05.03.2014 12:27, schrieb Alexey Kardashevskiy:
> On 03/05/2014 07:30 PM, Andreas Färber wrote:
>> Am 05.03.2014 03:50, schrieb Alexey Kardashevskiy:
>>> On 03/04/2014 01:55 PM, Andreas Färber wrote:
>>>> Hello,
>>>>
>>>> Prompted by Alexey's desire for tweakable PowerPCCPU properties but also by
>>>> Peter's wish for ARMCPU properties, this series sets out to align cpu_model
>>>> parsing across targets.
>>>>
>>>> QemuOpts would've been nice to use, but on the one hand x86 and sparc use
>>>> QemuOpts-incompatible +foo and -foo syntax (which accumulate rather than apply
>>>> immediately) and on the other linux-user and bsd-user don't use QemuOpts at all.
>>>>
>>>> The x86 implementation is closest to the proposed API, save for some laziness.
>>>> SPARC is brought in line. And as fallback for the remaining targets a new
>>>> implementation, derived from x86 but supporting only key=value format, is added.
>>>>
>>>> To facilitate using this infrastructure, a generic CPU init function is created.
>>>
>>>
>>> Besides the fact that this patchset does not support dynamic properties
>>> (added by object_property_add(), and I used it in my initial patchset),
>>
>> Why would that be? I am using QOM object_property_parse() just like on
>> x86 where we do have a mix of static and dynamic properties. Maybe you
>> are using object_property_add() in the wrong place? It should be used in
>> the instance_init function of the CPU - be it PowerPCCPU or a derived
>> family/model - i.e. before cpu_ppc_init() returns. The same is necessary
>> to support -global.
> 
> 
> cpu_ppc_init() calls cpu_generic_init() which does parsing before setting
> "realized" to "true". The only way to add a dynamic property here is to put
> object_property_add() in ppc_cpu_initfn() but it does not have CPU family
> hooks (unlike realizefn). Adding "compat" for every PPC CPU is ... wrong?
> 
> Where I tried adding dynamic property before is init_proc_POWER7
> (PowerPCCPUClass::init_proc) which is called from init_ppc_proc() which is
> called from ppc_cpu_realizefn() and this is too late.

I see now that the family's TypeInfo only specifies a class_init but not
an instance_init.

>>> that works for SPAPR, just need to implement property statically (tested).

It's been really long ago... could you please point me to what exactly
the property needs to be doing so that I get a feeling of whether a
static property is a solution after all or whether I need to somehow
tweak the family macro to allow for an instance_init? Like, does the
property need to be settable after realize?

Thanks,
Andreas

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

      reply	other threads:[~2014-03-09 16:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-04  2:55 [Qemu-devel] [PATCH qom-cpu 0/6] cpu: Unifying features parsing Andreas Färber
2014-03-04  2:55 ` [Qemu-devel] [PATCH qom-cpu 1/6] cpu: Introduce CPUClass::parse_features() hook Andreas Färber
2014-03-05 15:04   ` Igor Mammedov
2014-03-05 16:06     ` Andreas Färber
2014-03-05 16:57       ` Igor Mammedov
2014-03-05 22:31         ` Eduardo Habkost
2014-03-09 15:55           ` Andreas Färber
2014-03-09 15:45   ` Andreas Färber
2014-03-10 11:25     ` Igor Mammedov
2014-03-04  2:55 ` [Qemu-devel] [PATCH qom-cpu 2/6] target-sparc: Use error_report() for CPU error reporting Andreas Färber
2014-03-04  2:55 ` [Qemu-devel] [PATCH qom-cpu 3/6] target-sparc: Implement CPUClass::parse_features() for SPARCCPU Andreas Färber
2014-03-04  2:55 ` [Qemu-devel] [PATCH qom-cpu 4/6] target-sparc: Defer SPARCCPU feature inference to QOM realize Andreas Färber
2014-03-04  2:55 ` [Qemu-devel] [PATCH qom-cpu 5/6] cpu: Implement CPUClass::parse_features() for the rest of CPUs Andreas Färber
2014-03-04  2:55 ` [Qemu-devel] [PATCH qom-cpu 6/6] cpu: Factor out cpu_generic_init() Andreas Färber
2014-03-04 20:32 ` [Qemu-devel] [PATCH qom-cpu 0/6] cpu: Unifying features parsing Andreas Färber
2014-03-08 20:50   ` Mark Cave-Ayland
2014-03-09 16:19     ` Andreas Färber
2014-03-05  2:50 ` Alexey Kardashevskiy
2014-03-05  8:30   ` Andreas Färber
2014-03-05 11:27     ` Alexey Kardashevskiy
2014-03-09 16:11       ` Andreas Färber [this message]

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=531C92A5.1080604@suse.de \
    --to=afaerber@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=anthony@codemonkey.ws \
    --cc=ehabkost@redhat.com \
    --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 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).