Re: [Qemu-devel] [PATCH qom-cpu for-1.5 0/4] target-i386: X86CPU compatibility properties

["Andreas Färber" <afaerber@suse.de>]

Am 03.05.2013 18:46, schrieb Anthony Liguori:
> Andreas Färber <afaerber@suse.de> writes:
> 
>> Hello,
>>
>> It's easier adapting the infrastructure to our needs than working around it:
>> X86CPU already has QOM properties today. What's lacking is model subclasses,
>> and with the one X86CPU type its global properties are overwritten by models.
>> But we already know the designated naming scheme for the models!
>>
>> So let's simply prepare compat_props for CPU models and make sure they are
>> already picked up today.
>>
>> This works just fine for changing the 486 CPUID model value and avoids to
>> redo the PC part once we have X86CPU subclasses.
>> Tested using: ./QMP/qom-get /machine/icc-bridge/icc/child[0].model
> 
> So, what's left to do with subclass modelling?

Well, in the past there had been multiple approaches:

X86CPUInfo (me)
instance_init (proposed my PMM, no code)
class_init (me)
x86_def_t (me)
static properties (imammedo)

Either of the last three ran into issues/discussions for -cpu host.

Igor's proposal is touching on the same issue as this series:

qdev_set_global_properties() is run from device's instance_init, which
is run *before* derived classes add any QOM-style properties in theirs.
So for 1.6 I would rather like to amend our QOM infrastructure with an
.instance_post_init hook (prior art for qdev props: .class_base_init) or
otherwise allow to set global defaults for any device or QOM object than
converting perfectly fine QOM properties back into qdev static
properties, when it's all just for one single function call. :)

> How long are we going to need to carry something like this?

I've always been hoping to get subclasses done for the next release...
That said, it depends on whether we can find an agreeable solution for
the above when-do-we-set-globals problem. If we do need static
properties, Igor has a patch to that effect that looked okay.

> It's a clever work around but I'm a bit concerned that it would grow
> beyond cpu subclasses and that we'd be stuck with it forever.

I would've proposed to add a header comment indicating it's not to be
generally used, but experience shows such comments are rarely read.

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