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

[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.

At one point, I modeled this as a Vcc Pin with similar semantics except that 
instead of relying on a property accessor, the realize function would connect to 
the device's Vcc pin to the children's Vcc pins via a set of Wire objects (that 
just propagate Pin state).

This later model is too low level IMHO.  I think we should stick with the 
functional realize property which covers 99% of devices.  For the 1%, we can use 
pins or just have additional properties as appropriate.

Regards,

Anthony Liguori