From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhiFH-0005rs-TG for qemu-devel@nongnu.org; Mon, 02 Jan 2012 08:48:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RhiFG-0002Sg-Q3 for qemu-devel@nongnu.org; Mon, 02 Jan 2012 08:48:11 -0500 Received: from cantor2.suse.de ([195.135.220.15]:44362 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhiFG-0002SS-FL for qemu-devel@nongnu.org; Mon, 02 Jan 2012 08:48:10 -0500 Message-ID: <4F01B542.8000800@suse.de> Date: Mon, 02 Jan 2012 14:46:42 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <87ehvis3uj.fsf@trasno.mitica> In-Reply-To: <87ehvis3uj.fsf@trasno.mitica> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: Chris Wright , Peter Maydell , Developers qemu-devel , KVM devel mailing list Am 02.01.2012 13:09, schrieb Juan Quintela: > First of all, Happy New Year to everybody (even for the people whose > calendar is different O:-) +1 > Please send in any agenda items you are interested in covering. 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? * 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? Testing: A brief clarification on scope, goals and relations (overlap?) of all frameworks proposed might be better than a flame war? ;) Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg