From patchwork Mon Jan 7 18:20:48 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eduardo Habkost X-Patchwork-Id: 1941831 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 3DA713FED4 for ; Mon, 7 Jan 2013 18:20:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754754Ab3AGSUB (ORCPT ); Mon, 7 Jan 2013 13:20:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:64222 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754665Ab3AGSTx (ORCPT ); Mon, 7 Jan 2013 13:19:53 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r07IJBYc001536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jan 2013 13:19:11 -0500 Received: from blackpad.lan.raisama.net (vpn1-7-15.gru2.redhat.com [10.97.7.15]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r07IJA5S029368; Mon, 7 Jan 2013 13:19:10 -0500 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id 978CA203D3E; Mon, 7 Jan 2013 16:20:50 -0200 (BRST) From: Eduardo Habkost To: qemu-devel@nongnu.org Cc: libvir-list@redhat.com, kvm@vger.kernel.org, =?UTF-8?q?Andreas=20F=C3=A4rber?= , Igor Mammedov , Gleb Natapov , Marcelo Tosatti , Jiri Denemark Subject: [PATCH qom-cpu 7/7] target-i386: check/enforce: Check all feature words Date: Mon, 7 Jan 2013 16:20:48 -0200 Message-Id: <1357582848-16575-8-git-send-email-ehabkost@redhat.com> In-Reply-To: <1357582848-16575-1-git-send-email-ehabkost@redhat.com> References: <1357582848-16575-1-git-send-email-ehabkost@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org This adds the following feature words to the list of flags to be checked by kvm_check_features_against_host(): - cpuid_7_0_ebx_features - ext4_features - kvm_features - svm_features This will ensure the "enforce" flag works as it should: it won't allow QEMU to be started unless every flag that was requested by the user or defined in the CPU model is supported by the host. This patch may cause existing configurations where "enforce" wasn't preventing QEMU from being started to abort QEMU. But that's exactly the point of this patch: if a flag was not supported by the host and QEMU wasn't aborting, it was a bug in the "enforce" code. Signed-off-by: Eduardo Habkost --- Cc: Gleb Natapov Cc: Marcelo Tosatti Cc: kvm@vger.kernel.org Cc: libvir-list@redhat.com Cc: Jiri Denemark CCing libvirt people, as this is directly related to the planned usage of the "enforce" flag by libvirt. The libvirt team probably has a problem in their hands: libvirt should use "enforce" to make sure all requested flags are making their way into the guest (so the resulting CPU is always the same, on any host), but users may have existing working configurations where a flag is not supported by the guest and the user really doesn't care about it. Those configurations will necessarily break when libvirt starts using "enforce". One example where it may cause trouble for common setups: pc-1.3 wants the kvm_pv_eoi flag enabled by default (so "enforce" will make sure it is enabled), but the user may have an existing VM running on a host without pv_eoi support. That setup is unsafe today because live-migration between different host kernel versions may enable/disable pv_eoi silently (that's why we need the "enforce" flag to be used by libvirt), but the user probably would like to be able to live-migrate that VM anyway (and have libvirt to "just do the right thing"). One possible solution to libvirt is to use "enforce" only on newer machine-types, so existing machines with older machine-types will keep the unsafe host-dependent-ABI behavior, but at least would keep live-migration working in case the user is careful. I really don't know what the libvirt team prefers, but that's the situation today. The longer we take to make "enforce" strict as it should and make libvirt finally use it, more users will have VMs with migration-unsafe unpredictable guest ABIs. Changes v2: - Coding style fix Changes v3: - Added ext4_feature_name array --- target-i386/cpu.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/target-i386/cpu.c b/target-i386/cpu.c index a54c464..68cabcf 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -989,8 +989,9 @@ static int unavailable_host_feature(FeatureWordInfo *f, uint32_t mask) return 0; } -/* best effort attempt to inform user requested cpu flags aren't making - * their way to the guest. +/* Check if all requested cpu flags are making their way to the guest + * + * Returns 0 if all flags are supported by the host, non-zero otherwise. * * This function may be called only if KVM is enabled. */ @@ -1008,6 +1009,14 @@ static int kvm_check_features_against_host(x86_def_t *guest_def) FEAT_8000_0001_EDX }, {&guest_def->ext3_features, &host_def.ext3_features, FEAT_8000_0001_ECX }, + {&guest_def->ext4_features, &host_def.ext4_features, + FEAT_C000_0001_EDX }, + {&guest_def->cpuid_7_0_ebx_features, &host_def.cpuid_7_0_ebx_features, + FEAT_7_0_EBX }, + {&guest_def->svm_features, &host_def.svm_features, + FEAT_SVM }, + {&guest_def->kvm_features, &host_def.kvm_features, + FEAT_KVM }, }; assert(kvm_enabled());