From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjXFw-0007jY-Lu for qemu-devel@nongnu.org; Wed, 29 Oct 2014 13:42:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XjXFo-0001uZ-Lt for qemu-devel@nongnu.org; Wed, 29 Oct 2014 13:42:00 -0400 Received: from cantor2.suse.de ([195.135.220.15]:44517 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjXFo-0001uL-Fb for qemu-devel@nongnu.org; Wed, 29 Oct 2014 13:41:52 -0400 Message-ID: <545126A0.7070802@suse.de> Date: Wed, 29 Oct 2014 18:40:48 +0100 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1412365191-22858-1-git-send-email-ehabkost@redhat.com> <1412365191-22858-6-git-send-email-ehabkost@redhat.com> In-Reply-To: <1412365191-22858-6-git-send-email-ehabkost@redhat.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 5/6] target-i386: Don't enable nested VMX by default List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , qemu-devel@nongnu.org Cc: Paolo Bonzini , Aurelien Jarno , kvm@vger.kernel.org, Richard Henderson Am 03.10.2014 um 21:39 schrieb Eduardo Habkost: > TCG doesn't support VMX, and nested VMX is not enabled by default on th= e > KVM kernel module. >=20 > So, there's no reason to have VMX enabled by default on the core2duo an= d > coreduo CPU models, today. Even the newer Intel CPU model definitions > don't have it enabled. >=20 > In this case, we need machine-type compat code, as people may be runnin= g > the older machine-types on hosts that had VMX nesting enabled. >=20 > Signed-off-by: Eduardo Habkost > --- > hw/i386/pc_piix.c | 2 ++ > hw/i386/pc_q35.c | 2 ++ > target-i386/cpu.c | 8 ++++---- > 3 files changed, 8 insertions(+), 4 deletions(-) [...] > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > index 1e9fff9..c336003 100644 > --- a/target-i386/cpu.c > +++ b/target-i386/cpu.c > @@ -720,10 +720,10 @@ static X86CPUDefinition builtin_x86_defs[] =3D { > CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA | > CPUID_PSE36 | CPUID_VME | CPUID_ACPI | CPUID_SS, > /* Missing: CPUID_EXT_DTES64, CPUID_EXT_DSCPL, CPUID_EXT_EST, > - * CPUID_EXT_TM2, CPUID_EXT_XTPR, CPUID_EXT_PDCM */ > + * CPUID_EXT_TM2, CPUID_EXT_XTPR, CPUID_EXT_PDCM, CPUID_EXT_VM= X */ > .features[FEAT_1_ECX] =3D > CPUID_EXT_SSE3 | CPUID_EXT_MONITOR | CPUID_EXT_SSSE3 | > - CPUID_EXT_VMX | CPUID_EXT_CX16, > + CPUID_EXT_CX16, > .features[FEAT_8000_0001_EDX] =3D > CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX, > .features[FEAT_8000_0001_ECX] =3D [snip] 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=3Dkvm so that -cpu enforce works, but let accel=3Dtcg fail with features not implemented. 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