[v2,14/18] KVM: SVM: Check that the current CPU supports SVM in kvm_is_svm_supported()
Message ID | 20230310214232.806108-15-seanjc@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1114431wrd; Fri, 10 Mar 2023 13:47:12 -0800 (PST) X-Google-Smtp-Source: AK7set/m2moK2EqSHSnBcFjwZWMdDYCrcNDLba1t+aG0xksDMBK9neZKaSjAtY3jtabmSkCYdu6c X-Received: by 2002:a17:903:120b:b0:19a:b092:b31a with SMTP id l11-20020a170903120b00b0019ab092b31amr28428701plh.8.1678484832680; Fri, 10 Mar 2023 13:47:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678484832; cv=none; d=google.com; s=arc-20160816; b=VR+a0zsFgyFqmeDc8VrNfSOjQ7VQhuxHlYjq3PdYDL7fCbC1qmo8fibrOBeJG5qkuv xvFrpDY6ouDYO9MqJ/8LH+l4cM3oL7kE+gR4FmKXM4290ThEWHR38cONGBwL6gzhfvBG PeK5zHnlA4/98xVr9RSEOEqvZSlV8JPdwRiFO1eEaZdv7CtKlusWaTJffmHC9cFB72rm cZbrC9YZI8Vf29aNCKgd1iC315s1uY61wye0azaE4BYYpHCeGO20McxQOpFJ02Elxe1Y CVXUUlt4clVW998UWRkh9B3wKLu7x5XS13mENtQEaNjmScHvjS8IaxAWaYP6TjVOY6Tq 4UVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:reply-to:dkim-signature; bh=R1zMC0FqfyEV/0S9ZnbLP+wjU2iwXROZi5JXQooIbHQ=; b=pmx27S1JvCZKmuarxjqyiUgaISQbfO2UsvF15gqniv4BmrDfmajCUgxv7U3d2UjWxI L/GlR8McAuM3I23/YV12iuypwsZ1MSzy22mr6pQpY8dESs0jMmM81IS5O63p/abZ3uh7 MJ3XfUdK5BS0jMJpJ70ijwkNSYNtB0Y96SilNcaZJC/OZO2FQnrNJR5bE67NhxY6APAC qGvKa/YUtVeyQTfd35Naf2vDFCjz8j3KWi6MudEOqwAlno16iA6iFvo22jH3c8xG3pwN bguevfcbk0vqR9jjU7t3aEkImUkgQeiBsnv4U3KAcK5P5ZkpKelNT2/QI9pn6z6qKm6o /Bug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=qFNLiBFL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c17-20020a170902d49100b0019c92ca0d05si909502plg.340.2023.03.10.13.46.57; Fri, 10 Mar 2023 13:47:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=qFNLiBFL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231624AbjCJVom (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Fri, 10 Mar 2023 16:44:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231681AbjCJVoH (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 10 Mar 2023 16:44:07 -0500 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E419A2B9DF for <linux-kernel@vger.kernel.org>; Fri, 10 Mar 2023 13:43:17 -0800 (PST) Received: by mail-pl1-x649.google.com with SMTP id ju20-20020a170903429400b0019ea5ea044aso3500155plb.21 for <linux-kernel@vger.kernel.org>; Fri, 10 Mar 2023 13:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1678484584; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=R1zMC0FqfyEV/0S9ZnbLP+wjU2iwXROZi5JXQooIbHQ=; b=qFNLiBFLLwtMgF+IeChjoCJa+ve1zT5ko/h9MJUHy8G8CX+5NcXD0Y6sTpwQKG+qXP 4NqQn4eVqEyN1HTU7GFiP0F/jBTXTePyXlzK+IWl2IQ6EGzCrtkqnHUUDpWgjSChI0sf lafMTJDPi9IKPx1rvVse3jbOarLoqHrFYV+QEY0OQj5LEG8F18DItVyjpN5xcfAI6RCg lb1AYL8iUu/vqeb6TvGOPRXMRk1NMUUnwF4PPQrqWcmwlrGnqd2UMjgaFilM2hI2dQIa kAQQa4bHO4nfqHbxjuO1rm1hp/ImvvQqskELGWC3DgLpv86gtnF7tdIaG22ZkkjAJjRe 2QFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678484584; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R1zMC0FqfyEV/0S9ZnbLP+wjU2iwXROZi5JXQooIbHQ=; b=XWOXJcSvywpuCKhHYmUvqdRgh4vg8WGy2v028NXu5PSovWTXeZrYYTUemb7Q1G9CIt eTds4U7O3+U3M7x09Wy0zPfWo+gVE8y+jbTSAKedI/3wvlsPwTSAZfICWjPcFy7MOaaF qedT2UgLPW/tTi+RCOQaJWn25HHtzTHv/z2XucLh5GbiM5pyl3KGDlKwyGdqK5fQzu3X mcIVNNpwW1Ad031Q+60pNzjxUs/ikmcxGgl4yVWTXLrB6u/HA1uThbifZZG9Y5fhqS5F 7t6J28pjq9frEYZ2yeZ7Mr6OX4AWcA0ADn/nh/LvyFXclnDkjRAiuzZJjklkecrsFiUp oL2A== X-Gm-Message-State: AO0yUKUKM3IMAQsuuLOzgIeu1QcvAW9QWG4+4IUD1CIziaveOk2ZxEZc yn3JY2djMiRqA8co1Omj7m+UryfhMVI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a62:d14a:0:b0:592:5eb2:84ea with SMTP id t10-20020a62d14a000000b005925eb284eamr10759214pfl.4.1678484584488; Fri, 10 Mar 2023 13:43:04 -0800 (PST) Reply-To: Sean Christopherson <seanjc@google.com> Date: Fri, 10 Mar 2023 13:42:28 -0800 In-Reply-To: <20230310214232.806108-1-seanjc@google.com> Mime-Version: 1.0 References: <20230310214232.806108-1-seanjc@google.com> X-Mailer: git-send-email 2.40.0.rc1.284.g88254d51c5-goog Message-ID: <20230310214232.806108-15-seanjc@google.com> Subject: [PATCH v2 14/18] KVM: SVM: Check that the current CPU supports SVM in kvm_is_svm_supported() From: Sean Christopherson <seanjc@google.com> To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com> Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Andrew Cooper <Andrew.Cooper3@citrix.com>, Kai Huang <kai.huang@intel.com>, Chao Gao <chao.gao@intel.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760018911608579472?= X-GMAIL-MSGID: =?utf-8?q?1760018911608579472?= |
Series |
x86/reboot: KVM: Clean up "emergency" virt code
|
|
Commit Message
Sean Christopherson
March 10, 2023, 9:42 p.m. UTC
Check "this" CPU instead of the boot CPU when querying SVM support so that
the per-CPU checks done during hardware enabling actually function as
intended, i.e. will detect issues where SVM isn't support on all CPUs.
Disable migration for the use from svm_init() mostly so that the standard
accessors for the per-CPU data can be used without getting yelled at by
CONFIG_DEBUG_PREEMPT=y sanity checks. Preventing the "disabled by BIOS"
error message from reporting the wrong CPU is largely a bonus, as ensuring
a stable CPU during module load is a non-goal for KVM.
Link: https://lore.kernel.org/all/ZAdxNgv0M6P63odE@google.com
Cc: Kai Huang <kai.huang@intel.com>
Cc: Chao Gao <chao.gao@intel.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/svm/svm.c | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
Comments
On Fri, 2023-03-10 at 13:42 -0800, Sean Christopherson wrote: > Check "this" CPU instead of the boot CPU when querying SVM support so that > the per-CPU checks done during hardware enabling actually function as > intended, i.e. will detect issues where SVM isn't support on all CPUs. > > Disable migration for the use from svm_init() mostly so that the standard > accessors for the per-CPU data can be used without getting yelled at by > CONFIG_DEBUG_PREEMPT=y sanity checks. Preventing the "disabled by BIOS" > error message from reporting the wrong CPU is largely a bonus, as ensuring > a stable CPU during module load is a non-goal for KVM. > > Link: https://lore.kernel.org/all/ZAdxNgv0M6P63odE@google.com > Cc: Kai Huang <kai.huang@intel.com> > Cc: Chao Gao <chao.gao@intel.com> > Signed-off-by: Sean Christopherson <seanjc@google.com> Should we add: Fixes: c82a5c5c53c5 ("KVM: x86: Do compatibility checks when onlining CPU") As that commit introduced using raw_smp_processor_id() to get CPU id in kvm_is_svm_supported() and print the CPU id out in error message? > --- > arch/x86/kvm/svm/svm.c | 25 +++++++++++++++++++------ > 1 file changed, 19 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 2934f185960d..f04b61c3d9d8 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -520,18 +520,20 @@ static void svm_init_osvw(struct kvm_vcpu *vcpu) > vcpu->arch.osvw.status |= 1; > } > > -static bool kvm_is_svm_supported(void) > +static bool __kvm_is_svm_supported(void) > { > - int cpu = raw_smp_processor_id(); > + int cpu = smp_processor_id(); Since we have made sure __kvm_is_svm_supported() is always performed on a stable cpu, should we keep using raw_smp_processor_id()? It is faster than smp_processor_id() when CONFIG_DEBUG_PREEMPT=y, but yes the latter can help to catch bug. > + struct cpuinfo_x86 *c = &cpu_data(cpu); > + > u64 vm_cr; > > - if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD && > - boot_cpu_data.x86_vendor != X86_VENDOR_HYGON) { > + if (c->x86_vendor != X86_VENDOR_AMD && > + c->x86_vendor != X86_VENDOR_HYGON) { > pr_err("CPU %d isn't AMD or Hygon\n", cpu); > return false; > } > > - if (!boot_cpu_has(X86_FEATURE_SVM)) { > + if (!cpu_has(c, X86_FEATURE_SVM)) { > pr_err("SVM not supported by CPU %d\n", cpu); > return false; > } > @@ -550,9 +552,20 @@ static bool kvm_is_svm_supported(void) > return true; > } > > +static bool kvm_is_svm_supported(void) > +{ > + bool supported; > + > + migrate_disable(); > + supported = __kvm_is_svm_supported(); > + migrate_enable(); > + > + return supported; > +} > + > static int svm_check_processor_compat(void) > { > - if (!kvm_is_svm_supported()) > + if (!__kvm_is_svm_supported()) > return -EIO; > > return 0; > -- > 2.40.0.rc1.284.g88254d51c5-goog >
On Mon, Mar 13, 2023, Huang, Kai wrote: > On Fri, 2023-03-10 at 13:42 -0800, Sean Christopherson wrote: > > Check "this" CPU instead of the boot CPU when querying SVM support so that > > the per-CPU checks done during hardware enabling actually function as > > intended, i.e. will detect issues where SVM isn't support on all CPUs. > > > > Disable migration for the use from svm_init() mostly so that the standard > > accessors for the per-CPU data can be used without getting yelled at by > > CONFIG_DEBUG_PREEMPT=y sanity checks. Preventing the "disabled by BIOS" > > error message from reporting the wrong CPU is largely a bonus, as ensuring > > a stable CPU during module load is a non-goal for KVM. > > > > Link: https://lore.kernel.org/all/ZAdxNgv0M6P63odE@google.com > > Cc: Kai Huang <kai.huang@intel.com> > > Cc: Chao Gao <chao.gao@intel.com> > > Signed-off-by: Sean Christopherson <seanjc@google.com> > > Should we add: > > Fixes: c82a5c5c53c5 ("KVM: x86: Do compatibility checks when onlining CPU") > > As that commit introduced using raw_smp_processor_id() to get CPU id in > kvm_is_svm_supported() and print the CPU id out in error message? My vote is to not to add a Fixes because using raw_smp_processor_id() and not disabling migration for module probe case was deliberate and is safe. I don't want to give the impression that the existing code is functionally broken. The only quirk is that the reporting could be misleading. That said, I'm not against adding a Fixes tag, because I certainly can't argue against the reporting being flawed. > > --- > > arch/x86/kvm/svm/svm.c | 25 +++++++++++++++++++------ > > 1 file changed, 19 insertions(+), 6 deletions(-) > > > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > > index 2934f185960d..f04b61c3d9d8 100644 > > --- a/arch/x86/kvm/svm/svm.c > > +++ b/arch/x86/kvm/svm/svm.c > > @@ -520,18 +520,20 @@ static void svm_init_osvw(struct kvm_vcpu *vcpu) > > vcpu->arch.osvw.status |= 1; > > } > > > > -static bool kvm_is_svm_supported(void) > > +static bool __kvm_is_svm_supported(void) > > { > > - int cpu = raw_smp_processor_id(); > > + int cpu = smp_processor_id(); > > Since we have made sure __kvm_is_svm_supported() is always performed on a stable > cpu, should we keep using raw_smp_processor_id()? � > > It is faster than smp_processor_id() when CONFIG_DEBUG_PREEMPT=y, but yes the > latter can help to catch bug. Most kernels with any amount of CONFIG_DEBUG_* options enabled are comically slow anyways, I much prefer having the sanity checks than the performance.
On Mon, 2023-03-13 at 10:29 -0700, Sean Christopherson wrote: > On Mon, Mar 13, 2023, Huang, Kai wrote: > > On Fri, 2023-03-10 at 13:42 -0800, Sean Christopherson wrote: > > > Check "this" CPU instead of the boot CPU when querying SVM support so that > > > the per-CPU checks done during hardware enabling actually function as > > > intended, i.e. will detect issues where SVM isn't support on all CPUs. > > > > > > Disable migration for the use from svm_init() mostly so that the standard > > > accessors for the per-CPU data can be used without getting yelled at by > > > CONFIG_DEBUG_PREEMPT=y sanity checks. Preventing the "disabled by BIOS" > > > error message from reporting the wrong CPU is largely a bonus, as ensuring > > > a stable CPU during module load is a non-goal for KVM. > > > > > > Link: https://lore.kernel.org/all/ZAdxNgv0M6P63odE@google.com > > > Cc: Kai Huang <kai.huang@intel.com> > > > Cc: Chao Gao <chao.gao@intel.com> > > > Signed-off-by: Sean Christopherson <seanjc@google.com> > > > > Should we add: > > > > Fixes: c82a5c5c53c5 ("KVM: x86: Do compatibility checks when onlining CPU") > > > > As that commit introduced using raw_smp_processor_id() to get CPU id in > > kvm_is_svm_supported() and print the CPU id out in error message? > > My vote is to not to add a Fixes because using raw_smp_processor_id() and not disabling > migration for module probe case was deliberate and is safe. I don't want to give the > impression that the existing code is functionally broken. The only quirk is that > the reporting could be misleading. > > That said, I'm not against adding a Fixes tag, because I certainly can't argue > against the reporting being flawed. Yeah the only issue is the reporting. And I will leave this to others. > > > > --- > > > arch/x86/kvm/svm/svm.c | 25 +++++++++++++++++++------ > > > 1 file changed, 19 insertions(+), 6 deletions(-) > > > > > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > > > index 2934f185960d..f04b61c3d9d8 100644 > > > --- a/arch/x86/kvm/svm/svm.c > > > +++ b/arch/x86/kvm/svm/svm.c > > > @@ -520,18 +520,20 @@ static void svm_init_osvw(struct kvm_vcpu *vcpu) > > > vcpu->arch.osvw.status |= 1; > > > } > > > > > > -static bool kvm_is_svm_supported(void) > > > +static bool __kvm_is_svm_supported(void) > > > { > > > - int cpu = raw_smp_processor_id(); > > > + int cpu = smp_processor_id(); > > > > Since we have made sure __kvm_is_svm_supported() is always performed on a stable > > cpu, should we keep using raw_smp_processor_id()? � > > > > It is faster than smp_processor_id() when CONFIG_DEBUG_PREEMPT=y, but yes the > > latter can help to catch bug. > > Most kernels with any amount of CONFIG_DEBUG_* options enabled are comically slow > anyways, I much prefer having the sanity checks than the performance. Yeah fine to me.
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 2934f185960d..f04b61c3d9d8 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -520,18 +520,20 @@ static void svm_init_osvw(struct kvm_vcpu *vcpu) vcpu->arch.osvw.status |= 1; } -static bool kvm_is_svm_supported(void) +static bool __kvm_is_svm_supported(void) { - int cpu = raw_smp_processor_id(); + int cpu = smp_processor_id(); + struct cpuinfo_x86 *c = &cpu_data(cpu); + u64 vm_cr; - if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD && - boot_cpu_data.x86_vendor != X86_VENDOR_HYGON) { + if (c->x86_vendor != X86_VENDOR_AMD && + c->x86_vendor != X86_VENDOR_HYGON) { pr_err("CPU %d isn't AMD or Hygon\n", cpu); return false; } - if (!boot_cpu_has(X86_FEATURE_SVM)) { + if (!cpu_has(c, X86_FEATURE_SVM)) { pr_err("SVM not supported by CPU %d\n", cpu); return false; } @@ -550,9 +552,20 @@ static bool kvm_is_svm_supported(void) return true; } +static bool kvm_is_svm_supported(void) +{ + bool supported; + + migrate_disable(); + supported = __kvm_is_svm_supported(); + migrate_enable(); + + return supported; +} + static int svm_check_processor_compat(void) { - if (!kvm_is_svm_supported()) + if (!__kvm_is_svm_supported()) return -EIO; return 0;