From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rhso4-0006gj-7B for qemu-devel@nongnu.org; Mon, 02 Jan 2012 20:04:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rhso2-0001dT-Tb for qemu-devel@nongnu.org; Mon, 02 Jan 2012 20:04:48 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:48132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rhso2-0001dL-Ku for qemu-devel@nongnu.org; Mon, 02 Jan 2012 20:04:46 -0500 Received: by iagj37 with SMTP id j37so34867557iag.4 for ; Mon, 02 Jan 2012 17:04:45 -0800 (PST) Message-ID: <4F025428.7050508@codemonkey.ws> Date: Mon, 02 Jan 2012 19:04:40 -0600 From: Anthony Liguori 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: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Chris Wright , Peter Maydell , Developers qemu-devel , KVM devel mailing list , quintela@redhat.com On 01/02/2012 07:46 AM, Andreas Färber 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 meetings so I ended up doing a bunch of QOM conversions. In my latest qom-rebase branch, I've got qdev buses modeled through QOM which was pretty much the finishing touch. It's just a matter of how much time we 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 composition, we need to eliminate the qdev "everything has a parent bus" requirement. I 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 convert CPUState to a proper Object and make -cpu just be a short hand for -device x86-cpu,nx=off,mmx2=on,.... > a) Are > CPU features being refactored (standardized) for QOM or should we copy > 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 probably more likely that we have a CPUCommon interface that all of the CPUs implement for 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 of having devices register VMState descriptions, all device serialization happens through a virtual method and flows through the composition tree. > 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 scared to death of breaking things. So I'm looking to improve my ability to test more exotic things. There are some notes that I haven't responded to yet as I've been AFK for the past few days, but I will most likely tomorrow. Regards, Anthony Liguori > Regards, > Andreas >