From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37802 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Odk7C-0004Rs-Ox for qemu-devel@nongnu.org; Tue, 27 Jul 2010 09:22:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Odk7B-0002DY-MW for qemu-devel@nongnu.org; Tue, 27 Jul 2010 09:22:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44590) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Odk7B-0002DU-Bp for qemu-devel@nongnu.org; Tue, 27 Jul 2010 09:22:37 -0400 Message-ID: <4C4EDD98.50609@redhat.com> Date: Tue, 27 Jul 2010 15:22:32 +0200 From: Jes Sorensen MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KVM call agenda for July 27 References: <20100726212849.GB2651@x200.localdomain> <4C4E0C05.5030004@codemonkey.ws> <4C4E1A33.7050709@codemonkey.ws> <1280189608.4601.237.camel@x201> In-Reply-To: <1280189608.4601.237.camel@x201> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org On 07/27/10 02:13, Alex Williamson wrote: > On Mon, 2010-07-26 at 18:28 -0500, Anthony Liguori wrote: >> On 07/26/2010 05:28 PM, Anthony Liguori wrote: >>> On 07/26/2010 04:28 PM, Chris Wright wrote: >>>> Please send in any agenda items you are interested in covering. >>> >>> - 0.13 update >>> I'll pre-empt the 0.13 question with an answer. I'm just testing >>> the VNC changes and if all goes well, I'll tag tonight. >>> >>> Initial thinking is to keep 0.14 short and target Dec 1st. >>> >>> - if danpb can make it, would like to discuss -help output parsing >>> summary: help parsing is terrible, but given the fact that >>> capabilities is going to take a while to get totally right, would like >>> to discuss an interim solution that gives us more flexibility to do >>> reasonable things with the help output. >> >> - any additional input on probed_raw? > > - cpu model #s, does anyone know things that would break if we bumped > the qemu64 model up to 13 (or higher?) and made definitions for > Conroe/Penryn/Nehalem use more representative model #s? That was my topic for the call :) The currenct qemu64 cpu model is a mess, family 6, model 2 is not even a 64 bit processor, plus we enable a bunch of flags that didn't exist in those processors: pni, popcnt, cx16, sse4a, lm, nx, lahf_lm, svm, abm (if I got the list right). Jes