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