Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/02/2012 08:11 AM, Paolo Bonzini wrote:
> On 01/02/2012 02:46 PM, Andreas Färber wrote:
>> QOM: If Anthony is available, I'd be interested in hearing an update on
>> the roadmap. In particular,
>> * when can we expect to be able to model SoCs rather than CPUs? Will
>> this affect command line usage - are we going to have '-device
>> ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
>> container's default?
>> * are the announced remaining 3 series going to touch CPUState? a) Are
>> CPU features being refactored (standardized) for QOM or should we copy
>> current x86 code for controlling ARM FPU? b) Any plans for adding
>> inheritence, e.g., for CPU_COMMON and CPU reset?
>
> Also, Anthony, what are the remaining 3 series exactly? :)

2/4 is on the list.  It's adding the type infrastructure such that when you do 
-device e1000, as far as QOM is concerned you're creating an E1000 object which 
inherits from a PCIDevice, etc.

But device creation still more or less happens with qdev.  You couldn't directly 
create a useful E1000 device by doing object_new(TYPE_E1000).

I just effectively squashed 3/4 and 4/4 into a single series.  This new series 
(now 3/4) makes it so you can do object_new(TYPE_E1000).  It basically reduces 
qdev to just the management of bus relationships.

The new 4/4 series converts BusState to QOM.  The effect is that a BusState is 
an Object (but not a device).  The children are shown as links so the entire 
qdev tree is now just a subset of the QOM graph.

I think that's it for infrastructure series.  After that, the two areas I'm 
interested in focusing on are converting CPUs to qdev and then refactoring the 
pc machine init code to just essentially be a thin wrapper for object_new(TYPE_PC).

> In particular, we should decide as soon as possible about moving features up
> from Device to Object or to new intermediate classes (e.g. IntrospectableObject
> for properties?),

I think I move properties from Device to Object in either 2/4 or 3/4.  Anyway, 
that's my plan.

> because I would like to start dogfooding QOM.

Cool!

> Right now, we
> have legacy properties but qdev functions still poke directly into the structs
> rather than using them.

Yeah, I had some concerns about legacy properties before Christmas but I haven't 
fully context switched back in yet.  I'll try to remember what they were and 
send a note out.

>> * what's the effect on VMState? Will VMState continue to coexist with
>> QOM, or does QOM replace VMState at some point? Is it worth introducing
>> new size mechanisms now or should we postpone SD/AHCI migration until
>> QOM is merged?
>
> I think no. Postponing new device models (virtio-scsi) might make some sense,

I don't think postponing is really necessary.  Rebasing really isn't all that 
difficult as it turns out.  I would rather we take our time reviewing things and 
not rush into a new infrastructure.

> but VMState is definitely going to be with us for some time---at least it's not
> disappearing soon enough that we should halt any development in that area.

Yeah, as I mentioned in my other note, I think it's more or less orthogonal to QOM.

Regards,

Anthony Liguori

> Paolo
>