From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35944)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Xjk2v-0001mz-7g
	for qemu-devel@nongnu.org; Thu, 30 Oct 2014 03:21:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Xjk2m-000899-6R
	for qemu-devel@nongnu.org; Thu, 30 Oct 2014 03:21:25 -0400
Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]:40755)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Xjk2l-00088V-Vp
	for qemu-devel@nongnu.org; Thu, 30 Oct 2014 03:21:16 -0400
Received: by mail-wi0-f172.google.com with SMTP id bs8so3637089wib.5
	for <qemu-devel@nongnu.org>; Thu, 30 Oct 2014 00:21:14 -0700 (PDT)
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <5451E626.1000304@redhat.com>
Date: Thu, 30 Oct 2014 08:17:58 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1412365191-22858-1-git-send-email-ehabkost@redhat.com>
	<1412365191-22858-6-git-send-email-ehabkost@redhat.com>
	<545126A0.7070802@suse.de>
In-Reply-To: <545126A0.7070802@suse.de>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v3 5/6] target-i386: Don't enable nested
 VMX by default
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?ISO-8859-15?Q?Andreas_F=E4rber?= <afaerber@suse.de>, Eduardo Habkost <ehabkost@redhat.com>, qemu-devel@nongnu.org
Cc: Aurelien Jarno <aurelien@aurel32.net>, kvm@vger.kernel.org, Richard Henderson <rth@twiddle.net>


> Here I'm less certain what the best approach is. As you point out,
> there's an inconsistency that I agree should be fixed. I wonder however
> whether an approach similar to 3/6 for KVM only would be better? I.e.,
> have VMX as a sometimes-KVM-supported feature be listed in the model and
> filter it out for accel=kvm so that -cpu enforce works, but let
> accel=tcg fail with features not implemented.

This would mean that -cpu coreduo,enforce doesn't work on TCG, but -cpu
Nehalem,enforce works.  This does not make much sense to me.

In fact, I would even omit the x86_cpu_compat_set_features altogether.
The inclusion of vmx in these models was a mistake, and nested VMX is
not really useful with anything but "-cpu host" because there are too
many capabilities communicated via MSRs rather than CPUID.

Paolo