From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 3 Date: Mon, 02 Jan 2012 19:04:40 -0600 Message-ID: <4F025428.7050508@codemonkey.ws> 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 Cc: quintela@redhat.com, Chris Wright , Peter Maydell , Developers qemu-devel , KVM devel mailing list To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Return-path: Received: from mail-iy0-f174.google.com ([209.85.210.174]:43218 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752109Ab2ACBEq (ORCPT ); Mon, 2 Jan 2012 20:04:46 -0500 Received: by iaeh11 with SMTP id h11so30038568iae.19 for ; Mon, 02 Jan 2012 17:04:45 -0800 (PST) In-Reply-To: <4F01B542.8000800@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 01/02/2012 07:46 AM, Andreas F=E4rber wrote: > 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, The moons aligned and I ended up with a week before Christmas of no mee= tings so=20 I ended up doing a bunch of QOM conversions. In my latest qom-rebase branch, I've got qdev buses modeled through QOM= which=20 was pretty much the finishing touch. It's just a matter of how much ti= me we=20 need to merge everything. > * 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? This is all a bit tricky to get right. In order to exploit QOM for com= position,=20 we need to eliminate the qdev "everything has a parent bus" requirement= =2E I=20 believe that that is done in series 3/4. > * are the announced remaining 3 series going to touch CPUState? No, but that's the next thing I want to do. It should be trivial to co= nvert=20 CPUState to a proper Object and make -cpu just be a short hand for -dev= ice=20 x86-cpu,nx=3Doff,mmx2=3Don,.... > a) Are > CPU features being refactored (standardized) for QOM or should we cop= y > current x86 code for controlling ARM FPU? b) It will definitely be object properties. > Any plans for adding > inheritence, e.g., for CPU_COMMON and CPU reset? Initially, no, but in the long term, it might make sense. It's probabl= y more=20 likely that we have a CPUCommon interface that all of the CPUs implemen= t for=20 things like the soft TLB code. I'm not really sure yet. > * what's the effect on VMState? Will VMState continue to coexist with > QOM, or does QOM replace VMState at some point? VMState is sort of orthogonal to QOM. What I do want to change is that= instead=20 of having devices register VMState descriptions, all device serializati= on=20 happens through a virtual method and flows through the composition tree= =2E > Is it worth introducing > new size mechanisms now or should we postpone SD/AHCI migration until > QOM is merged? I need to look carefully at those patches. > Testing: A brief clarification on scope, goals and relations (overlap= ?) > of all frameworks proposed might be better than a flame war? ;) In short, with QOM, I'm touching an alarming amount of code and am scar= ed to=20 death of breaking things. So I'm looking to improve my ability to test= more=20 exotic things. There are some notes that I haven't responded to yet as I've been AFK f= or the=20 past few days, but I will most likely tomorrow. Regards, Anthony Liguori > Regards, > Andreas >