From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S79Q2-0003OT-32 for qemu-devel@nongnu.org; Mon, 12 Mar 2012 13:52:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S79Pv-00032k-IH for qemu-devel@nongnu.org; Mon, 12 Mar 2012 13:52:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S79Pv-00032c-9K for qemu-devel@nongnu.org; Mon, 12 Mar 2012 13:52:19 -0400 Date: Mon, 12 Mar 2012 19:52:09 +0200 From: Gleb Natapov Message-ID: <20120312175209.GI12353@redhat.com> References: <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> <4F5E1B1B.1040606@suse.de> <20120312165014.GA25451@otherpad.lan.raisama.net> <4F5E3532.4060003@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4F5E3532.4060003@suse.de> 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: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: "Liu, Jinsong" , Eduardo Habkost , libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Avi Kivity , Anthony Liguori , Igor Mammedov , Jiri Denemark , "arch@ovirt.org" On Mon, Mar 12, 2012 at 06:41:06PM +0100, Andreas F=C3=A4rber wrote: > Am 12.03.2012 17:50, schrieb Eduardo Habkost: > > On Mon, Mar 12, 2012 at 04:49:47PM +0100, Andreas F=C3=A4rber wrote: > >> 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 = talk > >>> about -cpu best above. I am talking about any CPU model with fixed me= aning > >>> (not host or best which are host cpu dependant). Lets take Nehalem for > >>> example (just to move from Westmere :)). Currently it has level=3D2. = 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=3D2) and pc-1.1 (with leve= l=3D11). > >>> 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 definiti= ons > >>> for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happe= ns > >>> if you'll try to run qemu-1.1 -cpu Westmere on Kernel < 3.3 (without > >>> PMU support)? Qemu will fail to start. > [...] > >> 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. > >=20 > > It is not unexpected magic. It would be a documented mechanism: > > "-cpu Nehalem-1.0" and "-cpu Nehalem-1.1" would have the same meaning > > every time, with any machine-type, but "-cpu Nehalem" would be an alias, > > whose meaning depends on the machine-type. > >=20 > > Otherwise we would be stuck with a broken "Nehalem" model forever, and > > we don't want that. >=20 > Not quite what I meant: In light of QOM we should be able to instantiate > a CPU based on its name and optional parameters IMO. No dependency on > the machine, please. An alias sure, but if the user explicitly says -cpu > Nehalem then on 1.1 it should always be an alias to Nehalem-1.1 whether > the machine is -M pc-0.15 or pc. If no -cpu was specified by the user, > then choosing a default of Nehalem-1.0 for pc-1.0 is fine. Just trying > to keep separate things separate here. >=20 Those things are not separate. If user will get Nehalem-1.1 with -M pc-0.15 on qemu-1.1 it will get broken VM. If user uses -M pc-0.15 it should get exactly same machine it gets by running qemu-0.15. Guest should not be able to tell the difference. This is the reason -M exists, anything else is a bug. -- Gleb.