qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH qom-cpu 0/6] cpu: Unifying features parsing


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH qom-cpu 0/6] cpu: Unifying features parsing
Date: Sun, 09 Mar 2014 17:11:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

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 via email to

[Prev in Thread] Current Thread [Next in Thread]