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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
