From nobody Thu Sep 11 16:10:51 2025 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 5A16FC04FE1 for ; Tue, 15 Aug 2023 20:38:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238415AbjHOUhs (ORCPT ); Tue, 15 Aug 2023 16:37:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238633AbjHOUhf (ORCPT ); Tue, 15 Aug 2023 16:37:35 -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 46D8C2101 for ; Tue, 15 Aug 2023 13:37:02 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-589c772be14so81533407b3.0 for ; Tue, 15 Aug 2023 13:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692131819; x=1692736619; 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=WBkpDKr6jj4NzlnIGGdQVal1P0a3ByasoO5IEWSIJRE=; b=PohXGEt5p5Gq1eWQMfSEBAlCwCuyTp0UUAhPLRCgxqzUZpMgn02SBiu69mZXoWEq3y 3ZvimOOCTpl9ZMhcK/3SP14PXFtJl02TzytZHA5VrIs+SxLBlTFJAtkwxwpIszrGxQyG ypiMSggFd6oqDl5CNl8HLMEeTp//ytZeEG1RV4iGa4fPCPfUUtGX76EHoruSxAd6waDS ilzsqaA+xcc1M22yoAx/4E9Y8WyWUj4ZXujOWv2hnid1bWf9iyRpweqgXAUtIzCFl8Gx Dpe/2zsa44Nj5cfs9qPSwK98v6C+6XwIl5ozo3wSr2dw9S7RFD0Ka0T65AiEf9w6pykt 7jiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692131819; x=1692736619; 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=WBkpDKr6jj4NzlnIGGdQVal1P0a3ByasoO5IEWSIJRE=; b=L02qBEYbf/JX1vfFn8HgtYcV4V/+9Eyf8Qh6Gp7rIBiAzFdey1meNRtKOsHC9G8QL5 UrLbSDq2NFW/vbtC5HQ7D2H+SXgqP1o9coJ/SyrXPJ8b7fHwH695VwsWZ2jxVSqhhvgD 2srYdN1qLaD5RaL6O0NsNQED4XxSNshIrJs7vD2a3BVsVsNef+S92SwIc6fIaNg8Y6yu lePBzf/R8m/9uauWjqOlPMZ31Hvrg3IGKCA57Y3u8iAXEAsv16/y1WpLvkuc97dKgweE pxDhNBxB5sdX1cGjA7SwQlx2KzoGzXx0yC16b3liO47txtSq/29fwAAX3TArp1rcw6b9 sbNw== X-Gm-Message-State: AOJu0YxJmv2wUhkdi86A3UhOuj61p/A/wC5XlIlQlhnh3LzJ/+Q5jiNQ XeAY2+rerud6f5nrVHFP1Rypnl0XMuw= X-Google-Smtp-Source: AGHT+IEsB6TpySeJzscsreqlViYCX5OPRs/9V0pFq6s7NBXcybCVD+S+fZLYmnQdMHuHjRmXkoZYZ4UlaF0= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:3013:b0:576:e268:903d with SMTP id ey19-20020a05690c301300b00576e268903dmr48638ywb.2.1692131819462; Tue, 15 Aug 2023 13:36:59 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 15 Aug 2023 13:36:40 -0700 In-Reply-To: <20230815203653.519297-1-seanjc@google.com> Mime-Version: 1.0 References: <20230815203653.519297-1-seanjc@google.com> X-Mailer: git-send-email 2.41.0.694.ge786442a9b-goog Message-ID: <20230815203653.519297-3-seanjc@google.com> Subject: [PATCH v3 02/15] 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, Zeng Guang , Yuan Yao 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 Reviewed-by: Yuan Yao --- 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 4ba43ae008cb..67e9f79fe059 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 5bdda75bfd10..9e4cd8b4a202 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -4779,28 +4779,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)); } @@ -4877,7 +4862,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.694.ge786442a9b-goog