From nobody Mon Feb 9 05:59:10 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9897C7EE29 for ; Wed, 7 Jun 2023 00:43:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240127AbjFGAnV (ORCPT ); Tue, 6 Jun 2023 20:43:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239981AbjFGAnR (ORCPT ); Tue, 6 Jun 2023 20:43:17 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 832BD1732 for ; Tue, 6 Jun 2023 17:43:16 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id d9443c01a7336-1b23f04e268so3024635ad.3 for ; Tue, 06 Jun 2023 17:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686098596; x=1688690596; 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=9+MS+yTKdJPUgAK9JMZ2lmcpf9TYn8U5kmreyrww4/k=; b=GGY+hlFot4AUKOibBQ139XChSkWEIYm+AJuH7ziOV3noh8d0xYGkgJheiWHDDf0Bed v9HBFZtZe4i3+/JpP0y5mcmRM90VCE64QPtXY6VRx6RGq1qcOOuXjYT0jA4Kj1t2WRgP I7CQwNOG28qJewg2eW7reUEZeizEeQ3gnhyc6tuBtXpyohzy/ROZV+bAkWvzOSz8fuB0 BERmi1KuOFmKn4OBfXrtV0eYz0H+yLMJRRkYwMj1LKV4YBX+UpG5Y0rs2D0CHay5djXA Q8CZmM+wz4focbAiFmowqNKrW6ZuzUN7GyXf21kBC31fvSbhbA7J1tzMq2oqTCcyutwo Xztg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686098596; x=1688690596; 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=9+MS+yTKdJPUgAK9JMZ2lmcpf9TYn8U5kmreyrww4/k=; b=aT3QMf2/aT79Eb6wz+QF59DbwM1kc7RoIBMqZiO4hMb0k1A6c5yXB5FWr+O1J/pQma iY446bUVCxmy8qbokcXaNwsc31cXWDeK9Tn9ldZh9kwfcLck23l7nRlFCzHgPyqa7T+m BydkUUK9vFsVR5ahr36r/3jbBKSIv4yn8pU7IbLLIKO2mZz5szRjgJ5Nt/AhE5ZO2MlO eREJHNy3DJU4bEEDzSnP87s+YN2jzt0coXLoPRnHuTzRDILdaArVlWoHB7YCZBKwXfjw rIKSNSspJOzwCrb38pdKdv6JZw75xwActi7g26hys3LgKVNfiZ1FbqW2l6f1XiUd/Ur6 x1fw== X-Gm-Message-State: AC+VfDx6GIkoKaqYCk8RhkhG83iSlhtptQoGgapBBcKZIoTePl22OQ0h 95miu6S/nFTppUB5fTJucNhsTVQCoJI= X-Google-Smtp-Source: ACHHUZ7CqvxrAff/0HHKCH+uMhqE9Ff8aPZiF/5N6ugn3nZaMd2KZSl8LkQmYc8KxfHAqBACT8z0dkPsMf8= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:cecf:b0:1b1:86ad:332d with SMTP id d15-20020a170902cecf00b001b186ad332dmr1234293plg.12.1686098596054; Tue, 06 Jun 2023 17:43:16 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 6 Jun 2023 17:43:09 -0700 In-Reply-To: <20230607004311.1420507-1-seanjc@google.com> Mime-Version: 1.0 References: <20230607004311.1420507-1-seanjc@google.com> X-Mailer: git-send-email 2.41.0.162.gfafddb0af9-goog Message-ID: <20230607004311.1420507-2-seanjc@google.com> Subject: [PATCH 1/2] KVM: x86: Snapshot host's MSR_IA32_ARCH_CAPABILITIES From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Gao , Xiaoyao Li , Pawan Gupta Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Snapshot the host's MSR_IA32_ARCH_CAPABILITIES, if it's supported, instead of reading the MSR every time KVM wants to query the host state, e.g. when initializing the default value during vCPU creation. The paths that query ARCH_CAPABILITIES aren't particularly performance sensitive, but creating vCPUs is a frequent enough operation that burning 8 bytes is a good trade-off. Alternatively, KVM could add a field in kvm_caps and thus skip the on-demand calculations entirely, but a pure snapshot isn't possible due to the way KVM handles the l1tf_vmx_mitigation module param. And unlike the other "supported" fields in kvm_caps, KVM doesn't enforce the "supported" value, i.e. KVM treats ARCH_CAPABILITIES like a CPUID leaf and lets userspace advertise whatever it wants. Those problems are solvable, but it's not clear there is real benefit versus snapshotting the host value, and grabbing the host value will allow additional cleanup of KVM's FB_CLEAR_CTRL code. Link: https://lore.kernel.org/all/20230524061634.54141-2-chao.gao@intel.com Cc: Chao Gao Cc: Xiaoyao Li Signed-off-by: Sean Christopherson Reviewed-by: Chao Gao Reviewed-by: Xiaoyao Li --- arch/x86/kvm/vmx/vmx.c | 22 ++++++---------------- arch/x86/kvm/x86.c | 13 +++++++------ arch/x86/kvm/x86.h | 1 + 3 files changed, 14 insertions(+), 22 deletions(-) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 2d9d155691a7..42d1148f933c 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -255,14 +255,9 @@ static int vmx_setup_l1d_flush(enum vmx_l1d_flush_stat= e l1tf) return 0; } =20 - if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) { - u64 msr; - - rdmsrl(MSR_IA32_ARCH_CAPABILITIES, msr); - if (msr & ARCH_CAP_SKIP_VMENTRY_L1DFLUSH) { - l1tf_vmx_mitigation =3D VMENTER_L1D_FLUSH_NOT_REQUIRED; - return 0; - } + if (host_arch_capabilities & ARCH_CAP_SKIP_VMENTRY_L1DFLUSH) { + l1tf_vmx_mitigation =3D VMENTER_L1D_FLUSH_NOT_REQUIRED; + return 0; } =20 /* If set to auto use the default l1tf mitigation method */ @@ -373,15 +368,10 @@ static int vmentry_l1d_flush_get(char *s, const struc= t kernel_param *kp) =20 static void vmx_setup_fb_clear_ctrl(void) { - u64 msr; - - if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES) && + if ((host_arch_capabilities & ARCH_CAP_FB_CLEAR_CTRL) && !boot_cpu_has_bug(X86_BUG_MDS) && - !boot_cpu_has_bug(X86_BUG_TAA)) { - rdmsrl(MSR_IA32_ARCH_CAPABILITIES, msr); - if (msr & ARCH_CAP_FB_CLEAR_CTRL) - vmx_fb_clear_ctrl_available =3D true; - } + !boot_cpu_has_bug(X86_BUG_TAA)) + vmx_fb_clear_ctrl_available =3D true; } =20 static __always_inline void vmx_disable_fb_clear(struct vcpu_vmx *vmx) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 7c7be4815eaa..7c2e796fa460 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -237,6 +237,9 @@ EXPORT_SYMBOL_GPL(enable_apicv); u64 __read_mostly host_xss; EXPORT_SYMBOL_GPL(host_xss); =20 +u64 __read_mostly host_arch_capabilities; +EXPORT_SYMBOL_GPL(host_arch_capabilities); + const struct _kvm_stats_desc kvm_vm_stats_desc[] =3D { KVM_GENERIC_VM_STATS(), STATS_DESC_COUNTER(VM, mmu_shadow_zapped), @@ -1612,12 +1615,7 @@ static bool kvm_is_immutable_feature_msr(u32 msr) =20 static u64 kvm_get_arch_capabilities(void) { - u64 data =3D 0; - - if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) { - rdmsrl(MSR_IA32_ARCH_CAPABILITIES, data); - data &=3D KVM_SUPPORTED_ARCH_CAP; - } + u64 data =3D host_arch_capabilities & KVM_SUPPORTED_ARCH_CAP; =20 /* * If nx_huge_pages is enabled, KVM's shadow paging will ensure that @@ -9492,6 +9490,9 @@ static int __kvm_x86_vendor_init(struct kvm_x86_init_= ops *ops) =20 kvm_init_pmu_capability(ops->pmu_ops); =20 + if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) + rdmsrl(MSR_IA32_ARCH_CAPABILITIES, host_arch_capabilities); + r =3D ops->hardware_setup(); if (r !=3D 0) goto out_mmu_exit; diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h index 82e3dafc5453..1e7be1f6ab29 100644 --- a/arch/x86/kvm/x86.h +++ b/arch/x86/kvm/x86.h @@ -323,6 +323,7 @@ fastpath_t handle_fastpath_set_msr_irqoff(struct kvm_vc= pu *vcpu); =20 extern u64 host_xcr0; extern u64 host_xss; +extern u64 host_arch_capabilities; =20 extern struct kvm_caps kvm_caps; =20 --=20 2.41.0.162.gfafddb0af9-goog