Re: [Qemu-devel] [PATCH qom-cpu 00/15 v8] target-i386: convert CPU features into properties, part 1

[Eduardo Habkost]

On Wed, Jun 05, 2013 at 07:04:59PM +0200, Andreas Färber wrote:
> Am 05.06.2013 16:39, schrieb Igor Mammedov:
> > On Wed, 05 Jun 2013 15:29:08 +0200
> > Andreas Färber <address@hidden> wrote:
> > 
> >> Am 05.06.2013 15:18, schrieb Igor Mammedov:
> >>> It's a rebase of v7 on current qom-cpu tree, since then some patches from 
> >>> it
> >>> were applied to master. Convertion of feature bits is left for part 2
> >>> since it's not ready yet.
> >>>
> >>> v7-v8:
> >>> * split out dynamic properties convertion patch into per property patches
> >>>   to simplify review
> >>> * drop feature bits convertion
> >>
> >> Why is conversion of dynamic properties to static properties still
> >> needed after I applied a solution to override values of dynamic
> >> properties with -global for 1.5?
> > Do you mean qdev_prop_set_globals_for_type() & co?
> 
> Yes.
> 
> > If yes, then I recall it was acceptable hack to permit more clean
> > approach for compat props fixes to work. And we promised Anthony to
> > get rid of it when possible.
> 
> Indeed, but no one talked about reverting to static properties as the
> solution. :) Instead I was talking about solving this very general
> problem at DeviceState / QOM level.

We have had this discussion before, and I remember Anthony saying that
anything set using global properties _must_ be static properties,
period.

That was the main motivation we even started doing the static properties
work, months ago.


> 
> > Now more to the point,
> > 
> > 1. if CPU are to be created with device_add(wich is still  a goal)
> >    cpu_x86_create() won't be created, so it leaves rules out compat
> >    properties set by qdev_prop_set_globals_for_type().
> 
> It does not rule it out, but I think we all agree that we do not want
> calls of it cluttered over subclasses.
> 
> Instead we have a very generic problem: instance_init is called
> recursively, parents first, so a parent class cannot do any instance
> initialization *after* its derived classes initialized the instance.
> That's contrary to how realize and other QOM methods work but in
> exchange for the flexibility put the burden of saving and calling the
> parent's implementation onto subclasses.
> 
> That's what I would like to change in some way, possibly a
> instance_post_init hook or the like, similar to how DeviceState got its
> own base class initialization hook to handle static props.
> That would not only keep the work low in this case but may also solve
> the virtio-net initialization problem reported elsewhere.

You mean this?
https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg00434.html

> 
[...]

-- 
Eduardo