From nobody Sun Feb 8 14:23:00 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 38968C0015E for ; Sat, 29 Jul 2023 01:17:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237275AbjG2BRL (ORCPT ); Fri, 28 Jul 2023 21:17:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237219AbjG2BQq (ORCPT ); Fri, 28 Jul 2023 21:16:46 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3ED149EA for ; Fri, 28 Jul 2023 18:16:29 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5704995f964so29395747b3.2 for ; Fri, 28 Jul 2023 18:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690593388; x=1691198188; 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=OeX+CuubSaKKTeg9YUHiYCwLGztaZPXmiwSd5vwTnGo=; b=tczXnxVR/+BbWdcXZzl16Zjac9Ua038CcCQZlGqLyrjqqJA8FnbTg//UO8FJYiqmLY bTheeO1XRmDgq5B0p1UTPzDHqUoZePinMfEwTVlLSLupYGg3UtaMSrQDuZLMBmksB1kY /ZibaeRhEWniSleStOuqcs+QbMglMUexLC3HWcSWhg+imS8D1XTSRDYw4VIGfDXngXiF yA0MLBkGp6BTuyJco3d6fa58/C31vKQ9PpcZId1xL2u3XuuFJTkdwby9axhAZX5MSkMf On5p9uy1VV3x+9bGcxgT7AO/fPmQ/vrmqcVD70Oe05qaAKI7xSOLVWDn9TNpD53phozU DXTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690593388; x=1691198188; 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=OeX+CuubSaKKTeg9YUHiYCwLGztaZPXmiwSd5vwTnGo=; b=eS+3od7w1DhAQVSv/aH0ulYzZxwlylvcRItfAfsZ3iz6SpFs9IcD+O45MLNLIVuQMl I8mCxSRYb9w71LfxRNlWJK0lN0yc7LKEhHHxDJmi/1WPP4Ngcei07/BA6SuomcmX3PgC Oa9kRxguSc6Q35acmipLl7hF72Mi5yD7/UBZDM9a4I9S0YIK0jcL7lnw2u6vJqHS2PXe 3xlrCp+g1LvQav7sLWQQlbT0mmdRl9E6g+PSP5d3Iwvz5L+MwP0pasZE8gisTfrmN9YM b3x+ep5JsHa0kv4u03u23Xo/516R3ORUeipvJ7FcwEYZ9wMfkT+n0n0m53Th+ybIFG1q G37Q== X-Gm-Message-State: ABy/qLbfKbDn7a6t+m91GWH0Bj3JQNJ7GjQVyPymbyxavg4gY1toUDAM kz/P7y7Jpi2S4TnwpyRx8G+xUEXfdq4= X-Google-Smtp-Source: APBJJlGBvNCfyxKuG1R4NNoZpfFF1I/ljW+Qw9NESSIYSbL8hQok5yLiRGghpWLn+saGaQJuw1Daom1ZinM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:c094:0:b0:c6a:caf1:e601 with SMTP id c142-20020a25c094000000b00c6acaf1e601mr18754ybf.13.1690593388698; Fri, 28 Jul 2023 18:16:28 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 28 Jul 2023 18:15:55 -0700 In-Reply-To: <20230729011608.1065019-1-seanjc@google.com> Mime-Version: 1.0 References: <20230729011608.1065019-1-seanjc@google.com> X-Mailer: git-send-email 2.41.0.487.g6d72f3e995-goog Message-ID: <20230729011608.1065019-9-seanjc@google.com> Subject: [PATCH v2 08/21] KVM: x86/mmu: Use KVM-governed feature framework to track "GBPAGES enabled" From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini , Vitaly Kuznetsov Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Maxim Levitsky Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Use the governed feature framework to track whether or not the guest can use 1GiB pages, and drop the one-off helper that wraps the surprisingly non-trivial logic surrounding 1GiB page usage in the guest. No functional change intended. Signed-off-by: Sean Christopherson --- arch/x86/kvm/cpuid.c | 17 +++++++++++++++++ arch/x86/kvm/governed_features.h | 2 ++ arch/x86/kvm/mmu/mmu.c | 20 +++----------------- 3 files changed, 22 insertions(+), 17 deletions(-) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index ef826568c222..f74d6c404551 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -312,11 +312,28 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu = *vcpu) { struct kvm_lapic *apic =3D vcpu->arch.apic; struct kvm_cpuid_entry2 *best; + bool allow_gbpages; =20 BUILD_BUG_ON(KVM_NR_GOVERNED_FEATURES > KVM_MAX_NR_GOVERNED_FEATURES); bitmap_zero(vcpu->arch.governed_features.enabled, KVM_MAX_NR_GOVERNED_FEATURES); =20 + /* + * If TDP is enabled, let the guest use GBPAGES if they're supported in + * hardware. The hardware page walker doesn't let KVM disable GBPAGES, + * i.e. won't treat them as reserved, and KVM doesn't redo the GVA->GPA + * walk for performance and complexity reasons. Not to mention KVM + * _can't_ solve the problem because GVA->GPA walks aren't visible to + * KVM once a TDP translation is installed. Mimic hardware behavior so + * that KVM's is at least consistent, i.e. doesn't randomly inject #PF. + * If TDP is disabled, honor *only* guest CPUID as KVM has full control + * and can install smaller shadow pages if the host lacks 1GiB support. + */ + allow_gbpages =3D tdp_enabled ? boot_cpu_has(X86_FEATURE_GBPAGES) : + guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES); + if (allow_gbpages) + kvm_governed_feature_set(vcpu, X86_FEATURE_GBPAGES); + best =3D kvm_find_cpuid_entry(vcpu, 1); if (best && apic) { if (cpuid_entry_has(best, X86_FEATURE_TSC_DEADLINE_TIMER)) diff --git a/arch/x86/kvm/governed_features.h b/arch/x86/kvm/governed_featu= res.h index 40ce8e6608cd..b29c15d5e038 100644 --- a/arch/x86/kvm/governed_features.h +++ b/arch/x86/kvm/governed_features.h @@ -5,5 +5,7 @@ BUILD_BUG() =20 #define KVM_GOVERNED_X86_FEATURE(x) KVM_GOVERNED_FEATURE(X86_FEATURE_##x) =20 +KVM_GOVERNED_X86_FEATURE(GBPAGES) + #undef KVM_GOVERNED_X86_FEATURE #undef KVM_GOVERNED_FEATURE diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index ec169f5c7dce..7b9104b054bc 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -4808,28 +4808,13 @@ static void __reset_rsvds_bits_mask(struct rsvd_bit= s_validate *rsvd_check, } } =20 -static bool guest_can_use_gbpages(struct kvm_vcpu *vcpu) -{ - /* - * If TDP is enabled, let the guest use GBPAGES if they're supported in - * hardware. The hardware page walker doesn't let KVM disable GBPAGES, - * i.e. won't treat them as reserved, and KVM doesn't redo the GVA->GPA - * walk for performance and complexity reasons. Not to mention KVM - * _can't_ solve the problem because GVA->GPA walks aren't visible to - * KVM once a TDP translation is installed. Mimic hardware behavior so - * that KVM's is at least consistent, i.e. doesn't randomly inject #PF. - */ - return tdp_enabled ? boot_cpu_has(X86_FEATURE_GBPAGES) : - guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES); -} - static void reset_guest_rsvds_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context) { __reset_rsvds_bits_mask(&context->guest_rsvd_check, vcpu->arch.reserved_gpa_bits, context->cpu_role.base.level, is_efer_nx(context), - guest_can_use_gbpages(vcpu), + guest_can_use(vcpu, X86_FEATURE_GBPAGES), is_cr4_pse(context), guest_cpuid_is_amd_or_hygon(vcpu)); } @@ -4906,7 +4891,8 @@ static void reset_shadow_zero_bits_mask(struct kvm_vc= pu *vcpu, __reset_rsvds_bits_mask(shadow_zero_check, reserved_hpa_bits(), context->root_role.level, context->root_role.efer_nx, - guest_can_use_gbpages(vcpu), is_pse, is_amd); + guest_can_use(vcpu, X86_FEATURE_GBPAGES), + is_pse, is_amd); =20 if (!shadow_me_mask) return; --=20 2.41.0.487.g6d72f3e995-goog