From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S76ZO-0005Kz-U9 for qemu-devel@nongnu.org; Mon, 12 Mar 2012 10:50:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S76Yx-0007xe-TP for qemu-devel@nongnu.org; Mon, 12 Mar 2012 10:49:52 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:54882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S76Yx-0007tS-Je for qemu-devel@nongnu.org; Mon, 12 Mar 2012 10:49:27 -0400 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 12 Mar 2012 08:49:02 -0600 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id A9E52C9006D for ; Mon, 12 Mar 2012 10:48:19 -0400 (EDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2CEmH1Z302310 for ; Mon, 12 Mar 2012 10:48:18 -0400 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2CEmGx8022190 for ; Mon, 12 Mar 2012 08:48:16 -0600 Message-ID: <4F5E0CAB.1010901@us.ibm.com> Date: Mon, 12 Mar 2012 09:48:11 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> In-Reply-To: <20120311161625.GN17882@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: libvir-list@redhat.com, qemu-devel@nongnu.org, Avi Kivity , Anthony Liguori , Jiri Denemark , "arch@ovirt.org" On 03/11/2012 11:16 AM, Gleb Natapov wrote: > On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote: >> On 03/11/2012 09:56 AM, Gleb Natapov wrote: >>> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: >>>> -cpu best wouldn't solve this. You need a read/write configuration >>>> file where QEMU probes the available CPU and records it to be used >>>> for the lifetime of the VM. >>> That what I thought too, but this shouldn't be the case (Avi's idea). >>> We need two things: 1) CPU model config should be per machine type. >>> 2) QEMU should refuse to start if it cannot create cpu exactly as >>> specified by model config. >> >> This would either mean: >> >> A. pc-1.1 uses -cpu best with a fixed mask for 1.1 >> >> B. pc-1.1 hardcodes Westmere or some other family >> > This would mean neither A nor B. May be it wasn't clear but I didn't talk > about -cpu best above. I am talking about any CPU model with fixed meaning > (not host or best which are host cpu dependant). Lets take Nehalem for > example (just to move from Westmere :)). Currently it has level=2. Eduardo > wants to fix it to be 11, but old guests, installed with -cpu Nehalem, > should see the same CPU exactly. How do you do it? Have different > Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11). > Lets get back to Westmere. It actually has level=11, but that's only > expose another problem. Kernel 3.3 and qemu-1.1 combo will support > architectural PMU which is exposed in cpuid leaf 10. We do not want > guests installed with -cpu Westmere and qemu-1.0 to see architectural > PMU after upgrade. How do you do it? Have different Westmere definitions > for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens > if you'll try to run qemu-1.1 -cpu Westmere on Kernel< 3.3 (without > PMU support)? Qemu will fail to start. So, you're essentially proposing that -cpu Westmere becomes a machine option and that we let the machines interpret it as they see fit? So --machine pc-1.0,cpu=Westmere would result in something different than --machine pc-1.1,cpu=Westmere? That's something pretty different than what we're doing today. I think that we would have a single CPUX86 object and that part of the pc initialization process was to create an appropriately configured CPUx86 object. Regards, Anthony Liguori