qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 8/8] qom: Make CPU a child of DeviceState


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 8/8] qom: Make CPU a child of DeviceState
Date: Wed, 12 Dec 2012 12:36:09 -0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Dec 12, 2012 at 03:27:24PM +0100, Igor Mammedov wrote:
> On Wed, 12 Dec 2012 11:59:01 -0200
> Eduardo Habkost <address@hidden> wrote:
> 
> > On Wed, Dec 12, 2012 at 02:34:08PM +0100, Andreas Färber wrote:
> > > Am 05.12.2012 17:49, schrieb Eduardo Habkost:
> > [...]
> > > >  static TypeInfo cpu_type_info = {
> > > >      .name = TYPE_CPU,
> > > > -    .parent = TYPE_OBJECT,
> > > > +    .parent = TYPE_DEVICE,
> > > >      .instance_size = sizeof(CPUState),
> > > >      .abstract = true,
> > > >      .class_size = sizeof(CPUClass),
> > > 
> > > This patch makes the CPU a device and looks good so far but does not
> > > initialize the devices in cpu_*_init() like Anthony did in his previous
> > > patch. I am unsure whether you forgot to do so or whether you wanted to
> > > help keep our new CPU code clean of old-style qdev_init_nofail() calls?
> > > Since you don't add a qdev initfn here the main difference will be the
> > > devices internally staying in "created" rather than "initialized" state.
> > 
> > I think I used a version without the qdev_init_nofail() as base for this
> > series (we had multiple proposals being sent in parallel, in the
> > beginning), and in the end I forgot that we had a version with those
> > calls being added.
> > 
> > The CPU classes don't set any DeviceClass.init() method, so in theory
> > the missing qdev_init() calls wouldn't make any difference by now. On
> > the other hand, keeping the device in "created" state sounds bad... but
> > maybe this acceptable while we are still converting the CPU realize()
> > functions to fit inside the DeviceState initialization abstraction?
> Testing shows that lack of qdev_create()/init() doesn't break anything so
> far. I was planing to send hot-plug RFC after properties and subclasses for
> x86 are done and temporally wrap x86_cpu_realize() inside DeviceClass.init()
> so we could use qdev_create()/init() and device_add() for CPU.

It seems to be easy to gradually replace the existing cpu_*_realize()
calls inside cpu_*_init() with qdev_init[_nofail]() calls (making
DeviceClas.init point to cpu_*_realize()), one architecture at a time.

I mean: one day we should kill the cpu_*_init() functions and make it
CPU creation/initialization generic code. But while we don't do that, a
simple cpu_*_realize()->qdev_init() replacement sounds trivial.

But first I want to understand the difference between DeviceClass.init()
and the proposed DeviceClass.realize() abstraction (they look exactly
the same to me). I just sent a question as reply to Andreas' realizefn
RFC.

> It's still on my TODO list. Perhaps after I resubmit properties series (I
> hope to do it this week), I'll redo hot-plug prototype using as a base my
> experimental subclasses branch
> https://github.com/imammedo/qemu/commits/x86-cpu-classes.WIP

-- 
Eduardo



reply via email to

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