From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhN50-0004sX-TU for qemu-devel@nongnu.org; Tue, 28 May 2013 12:49:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhN4w-0002Lj-9y for qemu-devel@nongnu.org; Tue, 28 May 2013 12:48:58 -0400 Received: from cantor2.suse.de ([195.135.220.15]:48945 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhN4w-0002Lc-13 for qemu-devel@nongnu.org; Tue, 28 May 2013 12:48:54 -0400 Message-ID: <51A4DFF4.4030106@suse.de> Date: Tue, 28 May 2013 18:48:52 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <51A0596D.1050300@redhat.com> <20130527120951.GA2580@otherpad.lan.raisama.net> <51A34FD0.7010902@redhat.com> <20130527130712.GB2580@otherpad.lan.raisama.net> <51A4DF60.2080600@redhat.com> In-Reply-To: <51A4DF60.2080600@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] target-i386: Disable CPUID_EXT_MONITOR when KVM is enabled List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Igor Mammedov , Bandan Das , Eduardo Habkost , qemu-devel@nongnu.org Am 28.05.2013 18:46, schrieb Paolo Bonzini: > Il 28/05/2013 18:34, Bandan Das ha scritto: >> Eduardo Habkost writes: >> >>> On Mon, May 27, 2013 at 02:21:36PM +0200, Paolo Bonzini wrote: >>>> Il 27/05/2013 14:09, Eduardo Habkost ha scritto: >>>>> On Sat, May 25, 2013 at 08:25:49AM +0200, Paolo Bonzini wrote: >>>>>> Il 25/05/2013 03:21, Bandan Das ha scritto: >>>>>>> There is one user-visible effect: "-cpu ...,enforce" will stop fa= iling >>>>>>> because of missing KVM support for CPUID_EXT_MONITOR. But that's = exactly >>>>>>> the point: there's no point in having CPU model definitions that = would >>>>>>> never work as-is with neither TCG or KVM. This patch is changing = the >>>>>>> meaning of (e.g.) "-machine ...,accel=3Dkvm -cpu Opteron_G3" to m= atch what >>>>>>> was already happening in practice. >>>>>> >>>>>> But then -cpu Opteron_G3 does not match a "real" Opteron G3. Is i= t >>>>>> worth it? >>>>> >>>>> No models match a "real" CPU this way, because neither TCG or KVM >>>>> support all features supported by a real CPU. I ask the opposite >>>>> question: is it worth maintaining an "accurate" CPU model definitio= n >>>>> that would never work without feature-bit tweaking in the command-l= ine? >>>> >>>> It would work with TCG. Changing TCG to KVM should not change hardw= are >>>> if you use "-cpu ...,enforce", so it is right that it fails when >>>> starting with KVM. >>>> >>> >>> Changing between KVM and TCG _does_ change hardware, today (with or >>> without check/enforce). All CPU models on TCG have features not >>> supported by TCG automatically removed. See the "if (!kvm_enabled())" >>> block at x86_cpu_realizefn(). >> >> Yes, this is exactly why I was inclined to remove the monitor flag.=20 >> We already have uses of kvm_enabled() to set (or remove) kvm specific = stuff, >> and this change is no different. >=20 > Do any of these affect something that is part of x86_def_t? The vendor comes to mind. Andreas >> I can see Paolo's point though, having=20 >> a common definition probably makes sense too. >=20 >>> (That's why I argue that we need separate classes/names for TCG and K= VM >>> modes. Otherwise our predefined models get less useful as they will >>> require low-level feature-bit fiddling on the libvirt side to make th= em >>> work as expected.) >> >> Agreed. From a user's perspective, I think the more a CPU model "just = works", >> whether it's KVM or TCG, the better. >=20 > Yes, that's right. But I think extending the same expectation to "-cpu > ...,enforce" is not necessary, and perhaps even wrong for "-cpu > ...,check" since it's only a warning rather than a fatal error. >=20 > Paolo >=20 --=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