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

[Anthony Liguori]

On 01/02/2012 07:46 AM, Andreas Färber wrote:
> Am 02.01.2012 13:09, schrieb Juan Quintela:
> > First of all, Happy New Year to everybody (even for the people whose
> > calendar is different O:-)
>
> +1
>
> > Please send in any agenda items you are interested in covering.
>
> QOM: If Anthony is available, I'd be interested in hearing an update on
> the roadmap. In particular,

The moons aligned and I ended up with a week before Christmas of no meetings so 
I ended up doing a bunch of QOM conversions.

In my latest qom-rebase branch, I've got qdev buses modeled through QOM which 
was pretty much the finishing touch.  It's just a matter of how much time we 
need to merge everything.

> * 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?

This is all a bit tricky to get right.  In order to exploit QOM for composition, 
we need to eliminate the qdev "everything has a parent bus" requirement.  I 
believe that that is done in series 3/4.

> * are the announced remaining 3 series going to touch CPUState?

No, but that's the next thing I want to do.  It should be trivial to convert 
CPUState to a proper Object and make -cpu just be a short hand for -device 
x86-cpu,nx=off,mmx2=on,....

> a) Are
> CPU features being refactored (standardized) for QOM or should we copy
> current x86 code for controlling ARM FPU? b)

It will definitely be object properties.

> Any plans for adding
> inheritence, e.g., for CPU_COMMON and CPU reset?

Initially, no, but in the long term, it might make sense.  It's probably more 
likely that we have a CPUCommon interface that all of the CPUs implement for 
things like the soft TLB code.  I'm not really sure yet.

> * what's the effect on VMState? Will VMState continue to coexist with
> QOM, or does QOM replace VMState at some point?

VMState is sort of orthogonal to QOM.  What I do want to change is that instead 
of having devices register VMState descriptions, all device serialization 
happens through a virtual method and flows through the composition tree.

> Is it worth introducing
> new size mechanisms now or should we postpone SD/AHCI migration until
> QOM is merged?

I need to look carefully at those patches.

> Testing: A brief clarification on scope, goals and relations (overlap?)
> of all frameworks proposed might be better than a flame war? ;)

In short, with QOM, I'm touching an alarming amount of code and am scared to 
death of breaking things.  So I'm looking to improve my ability to test more 
exotic things.

There are some notes that I haven't responded to yet as I've been AFK for the 
past few days, but I will most likely tomorrow.

Regards,

Anthony Liguori

> Regards,
> Andreas