From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 3 Date: Mon, 02 Jan 2012 15:11:44 +0100 Message-ID: <4F01BB20.7020200@redhat.com> References: <87ehvis3uj.fsf@trasno.mitica> <4F01B542.8000800@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE To: "kvm@vger.kernel.org" , qemu-devel Return-path: Received: from mail-yx0-f174.google.com ([209.85.213.174]:42366 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751930Ab2ABOLv (ORCPT ); Mon, 2 Jan 2012 09:11:51 -0500 Received: by yenm11 with SMTP id m11so8375680yen.19 for ; Mon, 02 Jan 2012 06:11:50 -0800 (PST) In-Reply-To: <4F01B542.8000800@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 01/02/2012 02:46 PM, Andreas F=E4rber 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) Ar= e > CPU features being refactored (standardized) for QOM or should we cop= y > 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=20 features up from Device to Object or to new intermediate classes (e.g.=20 IntrospectableObject for properties?), because I would like to start=20 dogfooding QOM. Right now, we have legacy properties but qdev function= s=20 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 introduci= ng > 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= =20 sense, but VMState is definitely going to be with us for some time---at= =20 least it's not disappearing soon enough that we should halt any=20 development in that area. Paolo