From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7ACI-0003Rm-Fc for qemu-devel@nongnu.org; Mon, 12 Mar 2012 14:42:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7ACG-00069i-Ko for qemu-devel@nongnu.org; Mon, 12 Mar 2012 14:42:18 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:47557) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7ACG-00069c-Gf for qemu-devel@nongnu.org; Mon, 12 Mar 2012 14:42:16 -0400 Received: by ggnj2 with SMTP id j2so3425745ggn.4 for ; Mon, 12 Mar 2012 11:42:15 -0700 (PDT) Message-ID: <4F5E4381.2010003@codemonkey.ws> Date: Mon, 12 Mar 2012 13:42:09 -0500 From: Anthony Liguori MIME-Version: 1.0 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> <20120312183036.GK20654@otherpad.lan.raisama.net> In-Reply-To: <20120312183036.GK20654@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: Eduardo Habkost Cc: "Liu, Jinsong" , Gleb Natapov , libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Avi Kivity , Igor Mammedov , Jiri Denemark , "arch@ovirt.org" , =?ISO-8859-1?Q?Andreas_F=E4rber?= On 03/12/2012 01:30 PM, Eduardo Habkost wrote: > On Mon, Mar 12, 2012 at 06:41:06PM +0100, Andreas Färber wrote: >> Am 12.03.2012 17:50, schrieb Eduardo Habkost: >>> On Mon, Mar 12, 2012 at 04:49:47PM +0100, Andreas Färber wrote: > [...] >>>> 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. >>> >>> 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. >>> >>> Otherwise we would be stuck with a broken "Nehalem" model forever, and >>> we don't want that. >> >> 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. > > As Gleb explained, things aren't really separated: > "qemu-1.1 -M pc-1.0 -cpu Nehalem" should result in the same machine as > "qemu-1.0 -cpu Nehalem", no difference should be visible to the guest. > simply make incompatible changes. So this is easy. CPU's need to be qdev/QOM and the various cpuid settings need to be done through qdev properties. Then you can just add globals to the machine definition. No different than what we do with virtio-blk. Regards, Anthony Liguori > >> >> Also keep in mind linux-user. There's no concept of a machine there, but >> there's a cpu_copy() function used for forking that tries to re-create >> the CPU based on its model. So currently cpu_*_init(env->cpu_model_str) >> needs to be able to recreate an identical CPU through the central code >> path, without access to a QEMUMachine. > > So just translate the CPU alias given to "-cpu" to the true CPU model > name as soon as possible, at the command-line-handling code, so the rest > of the code always see the true CPU model name. > > After all, the need to make the aliases is a command-line interface > compatibility problem, so it makes sense to handle this at the > command-line-handling code. >