Re: [Qemu-devel] [PATCH 07/23] target-i386: convert cpuid features into properties

[Eduardo Habkost]

On Thu, Oct 04, 2012 at 03:10:53PM +0200, Igor Mammedov wrote:
> On Thu, 04 Oct 2012 14:57:29 +0200
> Andreas Färber <address@hidden> wrote:
> 
> > Am 04.10.2012 14:43, schrieb Eduardo Habkost:
> > > On Thu, Oct 04, 2012 at 08:53:22AM +0200, Igor Mammedov wrote:
> > >> For x86 CPU classes we were going dynamically generate CPU classes and
> > >> store pointer to appropriate cpudef from builtin_x86_defs in class field
> > >> for each CPU class and then init default feature words values from this
> > >> field int x86_cpu_initfn().
> > >>
> > >> However with qdev_prop_set_globals() in device_initfn() that is called
> > >> before x86_cpu_initfn() it won't work because defaults in
> > >> x86_cpu_initfn() will overwrite whatever was set by
> > >> qdev_prop_set_globals().
> > > 
> > > We can set the default values on class_init, instead. The class_init
> > > function for each CPU model can get the x86_def_t struct as the data
> > > pointer.
> > 
> > Let's avoid going backwards here, the plan was to have imperative
> > initfns, so x86_def_t would go away, no?
> > 
> > I'm catching up my mail on multiple fronts and will continue review,
> > IIUC Blue already applied the CPU feature deduplification series so
> > according to your roadmap this series is next.
> > 
> I guess no, it's now cpu-as-device that should be next on a queue, since I'm
> rewriting this series to use static properties instead so CPU must be a
> device.

Whatever we decide on this thread about CPU properties, cpu-as-device
seems to be the obvious candidate for "next-in-the-queue", or at least
it can be written/discussed in parallel. I plan to submit a new RFC
soon.

> 
> Though work would be easier if static props we written&applied on top of
> this, it's not like we need working for CPU qdev_prop_set_globals() after this
> series.
> 
> 
> 

-- 
Eduardo