From nobody Thu Feb 12 02:42: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 68FD6C7EE26 for ; Wed, 3 May 2023 18:29:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230136AbjECS3R (ORCPT ); Wed, 3 May 2023 14:29:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229993AbjECS3L (ORCPT ); Wed, 3 May 2023 14:29:11 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E10507D99 for ; Wed, 3 May 2023 11:29:03 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-55a2648c164so73024577b3.2 for ; Wed, 03 May 2023 11:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683138543; x=1685730543; 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=bcUuJsmnNf1FE7EU8eKP0IPIgfKzwZXNJofkM8/MGEI=; b=0xWagrPwWS6KtZvncnYm+PQ1pC+fpjXwRTFHojXSiK4uCSQMd4zFwJsSHuDj1xngtw X70UtcGdZoTNm6sMNGsoYBdAg3rwStYXTsruvK0NzgmClrr33et/0m7gbrxNpYDLsIVS Mm6fiPPmS8lXwJoP3lX4/N0/MkHsMpSWqCzD0dQ/Ot8CitX06ZQbc/760jgIAa1KHVcO 33ST7LSGDTibEQwzj1Y9IBQlOCQ6eZsCel6Qsx6n57mnjKkNFHEtCqorrrZkB/kWq6TL plHi0VohADz3vEt2ZBATmqMV3d5rr62rcv0mmKXKL5Vk230w6Pi3RrwZUdhS4BFJOI+l H2rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683138543; x=1685730543; 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=bcUuJsmnNf1FE7EU8eKP0IPIgfKzwZXNJofkM8/MGEI=; b=N+vgBdtLqobivfPDXrOJAjTm8kS6XlP1gUPrzOW2szO2QYj4EUhRpLf82EV3EqwbnL 6bK1via0ApnvSsKOA7wUs7/Q+Vs1D6/2lwe4buU766k86UiPij3GjY9TfsfePxEQjjfs X6pIxRjKgL4QnUYO3zZnidVyOviPg5/7NkmUSBS83qz4WaAuZZ5p/x9tYr/6oVKJRg5r JId9NeCRE6TcmR58f1RXYIYdE+pqowvC83AUlVFJHodbTga+fj9UyJKQ9dqeyhzzYU5X V/5/r+6V0DFwsPwNy9c70n62ccyrXVR4LqAMMjgJKyqw1rOGykLImLg6+qbGJBttmqm7 vBKQ== X-Gm-Message-State: AC+VfDxMEZZuZwNqvyT7fUcxflPQI3sBmzB+E3CfBRKbghVVEHeGnKL8 rGcrNlYwv2LQ5OTbC9B2l7ehrKr97iI= X-Google-Smtp-Source: ACHHUZ5yBw+H5JFnlvjHVMd9MoBmVM7glR0pGbMbbeUTU9PaTeJ0Bxw15VjcwtQnkLers1iFUq4hwAvPdXg= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:4007:0:b0:545:1d7f:acbf with SMTP id l7-20020a814007000000b005451d7facbfmr12675966ywn.10.1683138543201; Wed, 03 May 2023 11:29:03 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 3 May 2023 11:28:50 -0700 In-Reply-To: <20230503182852.3431281-1-seanjc@google.com> Mime-Version: 1.0 References: <20230503182852.3431281-1-seanjc@google.com> X-Mailer: git-send-email 2.40.1.495.gc816e09b53d-goog Message-ID: <20230503182852.3431281-4-seanjc@google.com> Subject: [PATCH 3/5] KVM: x86: Use MTRR macros to define possible MTRR MSR ranges From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Wenyao Hai , Ke Guo 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 MTRR macros to identify the ranges of possible MTRR MSRs instead of bounding the ranges with a mismash of open coded values and unrelated MSR indices. Carving out the gap for the machine check MSRs in particular is confusing, as it's easy to incorrectly think the case statement handles MCE MSRs instead of skipping them. Drop the range-based funneling of MSRs between the end of the MCE MSRs and MTRR_DEF_TYPE, i.e. 0x2A0-0x2FF, and instead handle MTTR_DEF_TYPE as the one-off case that it is. Extract PAT (0x277) as well in anticipation of dropping PAT "handling" from the MTRR code. Keep the range-based handling for the variable+fixed MTRRs even though capturing unknown MSRs 0x214-0x24F is arguably "wrong". There is a gap in the fixed MTRRs, 0x260-0x267, i.e. the MTRR code needs to filter out unknown MSRs anyways, and using a single range generates marginally better code for the big switch statement. Signed-off-by: Sean Christopherson --- arch/x86/kvm/mtrr.c | 2 +- arch/x86/kvm/x86.c | 10 ++++++---- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c index 9fac1ec03463..d2c428f4ae42 100644 --- a/arch/x86/kvm/mtrr.c +++ b/arch/x86/kvm/mtrr.c @@ -28,7 +28,7 @@ static bool msr_mtrr_valid(unsigned msr) { switch (msr) { - case 0x200 ... 0x200 + 2 * KVM_NR_VAR_MTRR - 1: + case MTRRphysBase_MSR(0) ... MTRRphysMask_MSR(KVM_NR_VAR_MTRR - 1): case MSR_MTRRfix64K_00000: case MSR_MTRRfix16K_80000: case MSR_MTRRfix16K_A0000: diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index e7f78fe79b32..8b356c9d8a81 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3700,8 +3700,9 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct = msr_data *msr_info) return 1; } break; - case 0x200 ... MSR_IA32_MC0_CTL2 - 1: - case MSR_IA32_MCx_CTL2(KVM_MAX_MCE_BANKS) ... 0x2ff: + case MSR_IA32_CR_PAT: + case MTRRphysBase_MSR(0) ... MSR_MTRRfix4K_F8000: + case MSR_MTRRdefType: return kvm_mtrr_set_msr(vcpu, msr, data); case MSR_IA32_APICBASE: return kvm_set_apic_base(vcpu, msr_info); @@ -4108,9 +4109,10 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct= msr_data *msr_info) msr_info->data =3D kvm_scale_tsc(rdtsc(), ratio) + offset; break; } + case MSR_IA32_CR_PAT: case MSR_MTRRcap: - case 0x200 ... MSR_IA32_MC0_CTL2 - 1: - case MSR_IA32_MCx_CTL2(KVM_MAX_MCE_BANKS) ... 0x2ff: + case MTRRphysBase_MSR(0) ... MSR_MTRRfix4K_F8000: + case MSR_MTRRdefType: return kvm_mtrr_get_msr(vcpu, msr_info->index, &msr_info->data); case 0xcd: /* fsb frequency */ msr_info->data =3D 3; --=20 2.40.1.495.gc816e09b53d-goog