From patchwork Fri Dec 28 18:37:33 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eduardo Habkost X-Patchwork-Id: 208515 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 644002C00A3 for ; Sat, 29 Dec 2012 05:36:25 +1100 (EST) Received: from localhost ([::1]:50977 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Toen9-0004RN-Hy for incoming@patchwork.ozlabs.org; Fri, 28 Dec 2012 13:36:23 -0500 Received: from eggs.gnu.org ([208.118.235.92]:51195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Toemp-0004Ey-9x for qemu-devel@nongnu.org; Fri, 28 Dec 2012 13:36:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Toemn-0005Bt-OO for qemu-devel@nongnu.org; Fri, 28 Dec 2012 13:36:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Toemn-0005Bh-F1 for qemu-devel@nongnu.org; Fri, 28 Dec 2012 13:36:01 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBSIZw5m025488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Dec 2012 13:35:58 -0500 Received: from blackpad.lan.raisama.net (vpn1-6-233.gru2.redhat.com [10.97.6.233]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qBSIZvNW022875; Fri, 28 Dec 2012 13:35:58 -0500 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id AE88B203CF9; Fri, 28 Dec 2012 16:37:36 -0200 (BRST) From: Eduardo Habkost To: qemu-devel@nongnu.org Date: Fri, 28 Dec 2012 16:37:33 -0200 Message-Id: <1356719854-16401-2-git-send-email-ehabkost@redhat.com> In-Reply-To: <1356719854-16401-1-git-send-email-ehabkost@redhat.com> References: <1356719854-16401-1-git-send-email-ehabkost@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: kvm@vger.kernel.org, Gleb Natapov , Joerg Roedel , Marcelo Tosatti , Igor Mammedov , =?UTF-8?q?Andreas=20F=C3=A4rber?= Subject: [Qemu-devel] [PATCH 1/2] target-i386: kvm: -cpu host: use GET_SUPPORTED_CPUID for SVM features X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org The existing -cpu host code simply set every bit inside svm_features (initializing it to -1), and that makes it impossible to make the enforce/check options work properly when the user asks for SVM features explicitly in the command-line. So, instead of initializing svm_features to -1, use GET_SUPPORTED_CPUID to fill only the bits that are supported by the host (just like we do for all other CPUID feature words inside kvm_cpu_fill_host()). This will keep the existing behavior (as filter_features_for_kvm() already uses GET_SUPPORTED_CPUID to filter svm_features), but will allow us to properly check for KVM features inside kvm_check_features_against_host() later. For example, we will be able to make this: $ qemu-system-x86_64 -cpu ...,+pfthreshold,enforce refuse to start if the SVM "pfthreshold" feature is not supported by the host (after we fix kvm_check_features_against_host() to check SVM flags as well). Signed-off-by: Eduardo Habkost Reviewed-By: Igor Mammedov --- target-i386/cpu.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/target-i386/cpu.c b/target-i386/cpu.c index 3cd1cee..6e2d32d 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -897,13 +897,10 @@ static void kvm_cpu_fill_host(x86_def_t *x86_cpu_def) } } - /* - * Every SVM feature requires emulation support in KVM - so we can't just - * read the host features here. KVM might even support SVM features not - * available on the host hardware. Just set all bits and mask out the - * unsupported ones later. - */ - x86_cpu_def->svm_features = -1; + /* Other KVM-specific feature fields: */ + x86_cpu_def->svm_features = + kvm_arch_get_supported_cpuid(s, 0x8000000A, 0, R_EDX); + #endif /* CONFIG_KVM */ }