qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]