From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhicC-0001RG-NL for qemu-devel@nongnu.org; Mon, 02 Jan 2012 09:11:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RhicB-0005iK-9u for qemu-devel@nongnu.org; Mon, 02 Jan 2012 09:11:52 -0500 Received: from mail-yw0-f45.google.com ([209.85.213.45]:43092) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhicB-0005i6-7K for qemu-devel@nongnu.org; Mon, 02 Jan 2012 09:11:51 -0500 Received: by yhgg71 with SMTP id g71so10740493yhg.4 for ; Mon, 02 Jan 2012 06:11:50 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F01BB20.7020200@redhat.com> Date: Mon, 02 Jan 2012 15:11:44 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <87ehvis3uj.fsf@trasno.mitica> <4F01B542.8000800@suse.de> In-Reply-To: <4F01B542.8000800@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "kvm@vger.kernel.org" , qemu-devel 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