From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMfch-0007ry-MQ for qemu-devel@nongnu.org; Wed, 27 Aug 2014 11:59:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XMfca-00047v-6w for qemu-devel@nongnu.org; Wed, 27 Aug 2014 11:58:59 -0400 Received: from cantor2.suse.de ([195.135.220.15]:48372 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMfca-00047n-0b for qemu-devel@nongnu.org; Wed, 27 Aug 2014 11:58:52 -0400 Message-ID: <53FE0039.4070509@suse.de> Date: Wed, 27 Aug 2014 17:58:49 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1408999550-20321-1-git-send-email-ehabkost@redhat.com> <53FC83F5.2090905@redhat.com> <20140826180107.GD32084@thinpad.lan.raisama.net> <53FDDEF3.2000705@redhat.com> <20140827140535.GG32084@thinpad.lan.raisama.net> <53FDEC52.5040909@redhat.com> <20140827154213.GH32084@thinpad.lan.raisama.net> In-Reply-To: <20140827154213.GH32084@thinpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 0/6] target-i386: Make most CPU models work with "enforce" out of the box List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Paolo Bonzini Cc: Aurelien Jarno , qemu-devel@nongnu.org, kvm@vger.kernel.org Am 27.08.2014 17:42, schrieb Eduardo Habkost: > On Wed, Aug 27, 2014 at 04:33:54PM +0200, Paolo Bonzini wrote: >> Il 27/08/2014 16:05, Eduardo Habkost ha scritto: >>> On Wed, Aug 27, 2014 at 03:36:51PM +0200, Paolo Bonzini wrote: >>>> Il 26/08/2014 20:01, Eduardo Habkost ha scritto: >>>>> So maybe that's good news, as things can be simpler if we make both= TCG >>>>> and KVM have similar behavior: >>>>> >>>>> * qemu64: a conservative default that should work out of the box on >>>>> most systems, for both TCG and KVM. That's already the current st= atus, >>>>> we just need to document it. >>>>> >>>>> * -cpu host: for people who want every possible feature to be enabl= ed >>>>> (but without cross-version live-migration support). We can easily= add >>>>> support for "-cpu host" to TCG, too. >>>> >>>> This means that "-cpu host" has different meanings in KVM and TCG. = Is >>>> that an advantage or a disadvantage? >>> >>> It is the same meaning to me: "enable everything that's possible, >>> considering what's provided by the underlying accelerator". The "host= " >>> name is misleading, though, because on KVM it is close to the host CP= U, >>> but on TCG it depends solely on TCG's capabilities. >> >> True. It's not very intuitive, but it is the same concept for process= or >> capabilities. >> >> Though for some leaves that do not correspond to processor capabilitie= s, >> "-cpu host" does set them to the host values. This is not just the >> cache model, but also the family/model/stepping/vendor. >> >> For the TCG case, when running on a Nehalem it would be weird to see a >> Nehalem guest with SMAP or ADOX support... I'm not sure it would even >> work to have SVM with an Intel vendor. :) >=20 > In that case, the best family/model/stepping/vendor choice depends on > TCG capabilities (defined at compile time), not on the host CPU. >=20 > ...and that proves your point: if we aren't even using the host CPU > family/model/stepping, calling it "-cpu host" doesn't make much sense. > If it is so different from the host model, we can call it "qemu64" (and > do as you suggests below). Might that be an opportunity to reconsider a -cpu best or so, independent of its implementation, to avoid "host"? Regards, Andreas --=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