qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class
Date: Wed, 14 Mar 2012 15:01:56 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 03/14/2012 02:57 PM, Andreas Färber wrote:
Am 14.03.2012 20:48, schrieb Anthony Liguori:
On 03/14/2012 03:37 PM, Igor Mitsyanko wrote:
On 13.03.2012 3:13 PM, Andreas Färber wrote:

In SysBusDeviceClass etc. we use the specific object type, too.
Obviously my CPU is the first "new" QOM type, so we can go different
ways if we want to. As long as it's a CPU-specific mechanism, using the
specific type avoids some casts.

It will be easier to generalize later qdev code and not make special
case when
adding cpus.

I never heard anyone wanting to generalize reset so far. I don't think
it belongs into Object at least. Maybe DeviceState. Anthony? Paolo?


We can have a special object for this, let's call it ResetLine for
example, with
methods ResetLine::connect, ResetLine::assert or something like that.
Different
ResetLine objects could trigger reset of different sets of subdevices,
just like
real hardware can have several reset types (for example, STM32 has 3
different
reset types).

I've explored a bunch of different models for this.  My current thinking
is a realized:bool property that when set, would call a realize()
virtual method and when unset would call an unrealize() virtual method.
The default implementation of [un]realize() would propagate the change
to all composition children.

I've found that model not to work with today's qdev remainders: We often
have a dependency tree of initfn and init a.k.a. realize functions, so
that we can't clearly separate between the two to do recursive
processing. Unless we do a three-stage initialization of Object::initfn,
what-is-now-DeviceState::init, Object::realize.

Yes, there's quite a lot of refactoring to get to a two stage recursive init. This is why realized isn't a part of QOM/qdev today.

Regards,

Anthony Liguori


Andreas





reply via email to

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