[Top][All Lists]
[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: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class |
Date: |
Wed, 14 Mar 2012 20:57:03 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2 |
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.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
- [Qemu-devel] [PATCH RFC v4 38/44] ppc hw/: Don't use CPUState, (continued)
- [Qemu-devel] [PATCH RFC v4 38/44] ppc hw/: Don't use CPUState, Andreas Färber, 2012/03/09
- [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Andreas Färber, 2012/03/09
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Igor Mammedov, 2012/03/12
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Andreas Färber, 2012/03/13
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Paolo Bonzini, 2012/03/13
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Andreas Färber, 2012/03/13
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Paolo Bonzini, 2012/03/13
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Anthony Liguori, 2012/03/13
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Igor Mitsyanko, 2012/03/14
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Anthony Liguori, 2012/03/14
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class,
Andreas Färber <=
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Anthony Liguori, 2012/03/14
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Andreas Färber, 2012/03/14
- Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class, Anthony Liguori, 2012/03/14
[Qemu-devel] [PATCH RFC v4 00/20] QOM'ify ARM CPU, Andreas Färber, 2012/03/10
[Qemu-devel] [PATCH RFC v4 13/20] target-arm: Store VFP FPSID register in ARMCPUClass, Andreas Färber, 2012/03/10