|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] KVM call agenda for Tuesday 3 |
Date: | Mon, 02 Jan 2012 15:11:44 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 |
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? :)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?), because I would like to start dogfooding QOM. Right now, we have legacy properties but qdev functions still poke directly into the structs rather than using them.
* 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, 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.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |