From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S77VY-0004Ky-CR for qemu-devel@nongnu.org; Mon, 12 Mar 2012 11:50:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S77VO-00060E-7M for qemu-devel@nongnu.org; Mon, 12 Mar 2012 11:49:59 -0400 Received: from cantor2.suse.de ([195.135.220.15]:42526 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S77VN-0005zu-UM for qemu-devel@nongnu.org; Mon, 12 Mar 2012 11:49:50 -0400 Message-ID: <4F5E1B1B.1040606@suse.de> Date: Mon, 12 Mar 2012 16:49:47 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= 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 Content-Transfer-Encoding: quoted-printable 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: "Liu, Jinsong" , libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Avi Kivity , Anthony Liguori , Igor Mammedov , Jiri Denemark , "arch@ovirt.org" Am 11.03.2012 17:16, schrieb Gleb Natapov: > 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 ta= lk > about -cpu best above. I am talking about any CPU model with fixed mean= ing > (not host or best which are host cpu dependant). Lets take Nehalem for > example (just to move from Westmere :)). Currently it has level=3D2. Ed= uardo > 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=3D2) and pc-1.1 (with level=3D= 11). > Lets get back to Westmere. It actually has level=3D11, 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 definition= s > 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. This sounds pretty much like what Liu Jinsong and Jan are discussing in the TSC thread on qemu-devel. (cc'ing) IMO interpreting an explicit -cpu parameter depending on -M would be wrong. Changing the default CPU based on -M is fine with me. For an explicit argument we would need Westmere-1.0 analog to pc-1.0. Then the user gets what the user asks for, without unexpected magic. Note that on my qom-cpu-wip branch [1] (that I hope to have cleaned up and sent out by tomorrow), all built-in CPUs become statically registered QOM types. The external definitions that get passed in via -cpudef become dynamically registered QOM types; I took care to allow overriding existing classes with the specified -cpudef fields (but untested). Setting family, level, etc. for -cpu is done on the X86CPU object instance. [2] What I don't have yet are QOM properties to set the fields from, e.g., machine code, but those should be fairly easy to add. Andreas [1] http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-cpu-wip [2] http://repo.or.cz/w/qemu/afaerber.git/commit/8a6ede101a2722b790489989f21c= ad38d3e41fb5 --=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