From nobody Fri May 8 02:19:39 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 19C1BC433EF for ; Thu, 12 May 2022 22:27:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359174AbiELW13 (ORCPT ); Thu, 12 May 2022 18:27:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359139AbiELW1W (ORCPT ); Thu, 12 May 2022 18:27:22 -0400 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 152BD68FAE for ; Thu, 12 May 2022 15:27:21 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id ij27-20020a170902ab5b00b0015d41282214so3360593plb.9 for ; Thu, 12 May 2022 15:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=C1tmuGf3Kd7bX6AU3hgvhdPKig3pohM2CuCo9pbL7R4=; b=GQ3TiTInl8g97+ab53I7+wOlfYIibpi1MwqEhIfwQfpbg/6/HMjl/L86q4NTrWM0dM 05ZvPnReez1qICDspanXCUPjFsjzwBu0BBUj3kX8ciEISZBr6TIMzKbGZKLEY7J5FK18 sSJbmY2nlZXmhk9jpc02Uci9pJHtFV2qawWnjJJTDVt+W5U5vxt9rAOEjF/iSAFU0/qJ idb9XzQiNlN9Aj7g2scAGXMAESLrT3FQfUjRQl1Wo37TW81PWKygJJZU10A7FUzgGEaq 2J80DftcI5y7GHShiS9p3WCjfcA3j7X1J0GsmYJwXSJIQF2f/PbM8BMcri0IC+st8DV6 JFXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=C1tmuGf3Kd7bX6AU3hgvhdPKig3pohM2CuCo9pbL7R4=; b=D0BHTtlP522IbeIY0tWnkbUwidlXzCirpDjE5T77PHGZitTUffTrLAgsb5AnNdueN3 sz5EcxFO64YzVJEfifzsAckwuTIvlo66lPdjVy4jTKbd2rQ/d+glwoE4bSG9eLnnj5FL 2dE6pafEvLW8tLkzOEJjan9+Hp6P9+HZN7iwwjw4JZuLK+LCSqyGnhQgdD+UCug0ujZj 9XQAe6r1rkrP/+SNucbB9V0EqKYhGQmy5RcPYSrF0Qnvu8rUhWi8ZJZz4WgGkmS2TlYK 1EM2ufqFrgYf8sQDuMLFjdz/mKFRsCvwjD2Cfi9Bu/PcI5PbvgVP93RJoru8CZhjMdGV Unkg== X-Gm-Message-State: AOAM5319ADGlzBwd8D/xNPgpPy3ECw8lkwNcN9Dp7AkaZ8l5DDWXQIDF 6zHbV5zIQBtgan3chpUcQiz/yyupWpk= X-Google-Smtp-Source: ABdhPJxHlQ48LjPdMReroSi+205tvMnzQqeslUkAQ4n7oeIV1go/ikXM5Elxq2fyC/ZXARh+nVKIAts+k58= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a62:31c1:0:b0:50a:4909:2691 with SMTP id x184-20020a6231c1000000b0050a49092691mr1511291pfx.64.1652394440586; Thu, 12 May 2022 15:27:20 -0700 (PDT) Reply-To: Sean Christopherson Date: Thu, 12 May 2022 22:27:14 +0000 In-Reply-To: <20220512222716.4112548-1-seanjc@google.com> Message-Id: <20220512222716.4112548-2-seanjc@google.com> Mime-Version: 1.0 References: <20220512222716.4112548-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.550.gb090851708-goog Subject: [PATCH 1/3] KVM: x86: Signal #GP, not -EPERM, on bad WRMSR(MCi_CTL/STATUS) From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jue Wang Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Return '1', not '-1', when handling an illegal WRMSR to a MCi_CTL or MCi_STATUS MSR. The behavior of "all zeros' or "all ones" for CTL MSRs is architectural, as is the "only zeros" behavior for STATUS MSRs. I.e. the intent is to inject a #GP, not exit to userspace due to an unhandled emulation case. Returning '-1' gets interpreted as -EPERM up the stack and effecitvely kills the guest. Fixes: 890ca9aefa78 ("KVM: Add MCE support") Fixes: 9ffd986c6e4e ("KVM: X86: #GP when guest attempts to write MCi_STATUS= register w/o 0") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson --- arch/x86/kvm/x86.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 8ee8c91fa762..bc6db58975dc 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3233,13 +3233,13 @@ static int set_msr_mce(struct kvm_vcpu *vcpu, struc= t msr_data *msr_info) */ if ((offset & 0x3) =3D=3D 0 && data !=3D 0 && (data | (1 << 10)) !=3D ~(u64)0) - return -1; + return 1; =20 /* MCi_STATUS */ if (!msr_info->host_initiated && (offset & 0x3) =3D=3D 1 && data !=3D 0) { if (!can_set_mci_status(vcpu)) - return -1; + return 1; } =20 vcpu->arch.mce_banks[offset] =3D data; --=20 2.36.0.550.gb090851708-goog From nobody Fri May 8 02:19:39 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 A598DC433EF for ; Thu, 12 May 2022 22:27:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359164AbiELW1b (ORCPT ); Thu, 12 May 2022 18:27:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359148AbiELW1X (ORCPT ); Thu, 12 May 2022 18:27:23 -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 BCD5B69484 for ; Thu, 12 May 2022 15:27:22 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id t14-20020a1709028c8e00b0015cf7e541feso3369398plo.1 for ; Thu, 12 May 2022 15:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=bSUiUXGuiZeZXDy6szRyl5Pb0BlIGgSml446k/D2EYc=; b=L4h+SAkPbx0grNeYQbaXxmVWIV5Ls1B38Oy26hddUO821qYdicU61uy4E2aQvj+5HO oNfcDCOz1Wbb/+FaJe+Ha0DZNYA10qc5mJbH5eesdxw6zZFIa7Nm43GG0Es5gefL4vmj 3xoVEkQC7ji8RztiX7tBFxdj/E7NM9WfLqdtIfHTfCKAc1Cq7ccAIOQSS4TIHRRHeGQX KNWDY3TnfbQe0bLKrp5v/EWqNv3Uge1TI71goS9hgYf0tY2A0hT0IF0QGcswXN/x8mEG +XvoddC26T1aWtOmbw3JYMwh6Lbfj335+oXaXNXQ3DkNRKpwsEgFV81U/rviK+pIVNzy sc5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=bSUiUXGuiZeZXDy6szRyl5Pb0BlIGgSml446k/D2EYc=; b=ayAaUUaaEymdCoes/fnwbmLAqynA9BBaB2xRiSeBtBGs/XzDV1frcAgF13kdg91QyF WEe23pRT/g2W8Y39hsF5x/WisYGEw7HBldKD2XWYwZzHxUNeYzvp+QWD5mzY9SWIpSEE fcNnx8fZWSl5gvHrZnbkefho+glp9Nxt2nPJeqj+tr7r+/mpekVLvwvaGOB1TcsT9737 LFza5UvcYaHNOsHypsGTC5BZDcC0+9a9Z8wad2DASmJd6nhN/Ncz1ulhcLfkKD4UTVHP C1zBvarwqFRd37dp5ggB1HuEw+5iujxUWgH7EZRf+dLdJyTravv/uRZNSEf4mRaU40a4 Adqg== X-Gm-Message-State: AOAM532oN+NoD9Gw+Z1ncs5fYWSiEmbPiRSpb8nyIz4vogIxQ3qKpgg+ 1V+awUwkDxNbPBnm83MHI5ILgKQPFXA= X-Google-Smtp-Source: ABdhPJy78pw9H01EQxvilUuvJI5YT+rh2PXQQ9qGJcQZE39wAkzjFRmskOhAGvnaE0zX4hrAicRF44HQIeo= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:903:41c9:b0:15e:ae15:294f with SMTP id u9-20020a17090341c900b0015eae15294fmr1914969ple.44.1652394442293; Thu, 12 May 2022 15:27:22 -0700 (PDT) Reply-To: Sean Christopherson Date: Thu, 12 May 2022 22:27:15 +0000 In-Reply-To: <20220512222716.4112548-1-seanjc@google.com> Message-Id: <20220512222716.4112548-3-seanjc@google.com> Mime-Version: 1.0 References: <20220512222716.4112548-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.550.gb090851708-goog Subject: [PATCH 2/3] KVM: x86: Use explicit case-statements for MCx banks in {g,s}et_msr_mce() From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jue Wang 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 an explicit case statement to grab the full range of MCx bank MSRs in {g,s}et_msr_mce(), and manually check only the "end" (the number of banks configured by userspace may be less than the max). The "default" trick works, but is a bit odd now, and will be quite odd if/when support for accessing MCx_CTL2 MSRs is added, which has near identical logic. Hoist "offset" to function scope so as to avoid curly braces for the case statement, and because MCx_CTL2 support will need the same variables. Opportunstically clean up the comment about allowing bit 10 to be cleared from bank 4. No functional change intended. Cc: Jue Wang Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson --- arch/x86/kvm/x86.c | 71 ++++++++++++++++++++++++---------------------- 1 file changed, 37 insertions(+), 34 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index bc6db58975dc..7e685ea9882b 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3206,6 +3206,7 @@ static int set_msr_mce(struct kvm_vcpu *vcpu, struct = msr_data *msr_info) unsigned bank_num =3D mcg_cap & 0xff; u32 msr =3D msr_info->index; u64 data =3D msr_info->data; + u32 offset, last_msr; =20 switch (msr) { case MSR_IA32_MCG_STATUS: @@ -3219,32 +3220,33 @@ static int set_msr_mce(struct kvm_vcpu *vcpu, struc= t msr_data *msr_info) return 1; vcpu->arch.mcg_ctl =3D data; break; + case MSR_IA32_MC0_CTL ... MSR_IA32_MCx_CTL(KVM_MAX_MCE_BANKS) - 1: + last_msr =3D MSR_IA32_MCx_CTL(bank_num) - 1; + if (msr > last_msr) + return 1; + + offset =3D array_index_nospec(msr - MSR_IA32_MC0_CTL, + last_msr + 1 - MSR_IA32_MC0_CTL); + + /* + * Only 0 or all 1s can be written to IA32_MCi_CTL, all other + * values are architecturally undefined. But, some Linux + * kernels clear bit 10 in bank 4 to workaround a BIOS/GART TLB + * issue on AMD K8s, allow bit 10 to be clear when setting all + * other bits in order to avoid an uncaught #GP in the guest. + */ + if ((offset & 0x3) =3D=3D 0 && + data !=3D 0 && (data | (1 << 10)) !=3D ~(u64)0) + return 1; + + /* MCi_STATUS */ + if (!msr_info->host_initiated && (offset & 0x3) =3D=3D 1 && + data !=3D 0 && !can_set_mci_status(vcpu)) + return 1; + + vcpu->arch.mce_banks[offset] =3D data; + break; default: - if (msr >=3D MSR_IA32_MC0_CTL && - msr < MSR_IA32_MCx_CTL(bank_num)) { - u32 offset =3D array_index_nospec( - msr - MSR_IA32_MC0_CTL, - MSR_IA32_MCx_CTL(bank_num) - MSR_IA32_MC0_CTL); - - /* only 0 or all 1s can be written to IA32_MCi_CTL - * some Linux kernels though clear bit 10 in bank 4 to - * workaround a BIOS/GART TBL issue on AMD K8s, ignore - * this to avoid an uncatched #GP in the guest - */ - if ((offset & 0x3) =3D=3D 0 && - data !=3D 0 && (data | (1 << 10)) !=3D ~(u64)0) - return 1; - - /* MCi_STATUS */ - if (!msr_info->host_initiated && - (offset & 0x3) =3D=3D 1 && data !=3D 0) { - if (!can_set_mci_status(vcpu)) - return 1; - } - - vcpu->arch.mce_banks[offset] =3D data; - break; - } return 1; } return 0; @@ -3789,6 +3791,7 @@ static int get_msr_mce(struct kvm_vcpu *vcpu, u32 msr= , u64 *pdata, bool host) u64 data; u64 mcg_cap =3D vcpu->arch.mcg_cap; unsigned bank_num =3D mcg_cap & 0xff; + u32 offset, last_msr; =20 switch (msr) { case MSR_IA32_P5_MC_ADDR: @@ -3806,16 +3809,16 @@ static int get_msr_mce(struct kvm_vcpu *vcpu, u32 m= sr, u64 *pdata, bool host) case MSR_IA32_MCG_STATUS: data =3D vcpu->arch.mcg_status; break; - default: - if (msr >=3D MSR_IA32_MC0_CTL && - msr < MSR_IA32_MCx_CTL(bank_num)) { - u32 offset =3D array_index_nospec( - msr - MSR_IA32_MC0_CTL, - MSR_IA32_MCx_CTL(bank_num) - MSR_IA32_MC0_CTL); + case MSR_IA32_MC0_CTL ... MSR_IA32_MCx_CTL(KVM_MAX_MCE_BANKS) - 1: + last_msr =3D MSR_IA32_MCx_CTL(bank_num) - 1; + if (msr > last_msr) + return 1; =20 - data =3D vcpu->arch.mce_banks[offset]; - break; - } + offset =3D array_index_nospec(msr - MSR_IA32_MC0_CTL, + last_msr + 1 - MSR_IA32_MC0_CTL); + data =3D vcpu->arch.mce_banks[offset]; + break; + default: return 1; } *pdata =3D data; --=20 2.36.0.550.gb090851708-goog From nobody Fri May 8 02:19:39 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 32D3AC433F5 for ; Thu, 12 May 2022 22:27:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359187AbiELW1e (ORCPT ); Thu, 12 May 2022 18:27:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359165AbiELW1Z (ORCPT ); Thu, 12 May 2022 18:27:25 -0400 Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com [IPv6:2607:f8b0:4864:20::104a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B867369727 for ; Thu, 12 May 2022 15:27:24 -0700 (PDT) Received: by mail-pj1-x104a.google.com with SMTP id m6-20020a17090a730600b001d9041534e4so3390772pjk.7 for ; Thu, 12 May 2022 15:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=y6gb0U2+lLyl/JLfdo770ZdpJj+aiCLx3/RH8sebC6g=; b=kEP9p9p6ty8/Cn8cm6dGGrIzXSWlTeD922G12T3rUIRfkqyIxLiFDIdV6tNBMqYigy 9ouHWupdaewZjaLRmHYZ/JL4yB/ZAV7O17Z0fwvGj2/iIt+gRZvfAaRfkSUACbXVm29k lgjMnz8qoEKLSuKPDHiHfWHk+dnEbQLea8ksKSyZW4K0tocXBIh9PsAk3+4m0AMkKjQE tpLyygojrv2nLbMp4P4mahrE/sVfFdu+EaCt+/4VO2Ni3+WkuVrweTmq8GhcAansyS1I eByUUhClwyruTFsBBVTnF24SrSjgX8S4AAer3b+8hAZf/xzxFRMqwMnVFpYYGpGfilNz 82PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=y6gb0U2+lLyl/JLfdo770ZdpJj+aiCLx3/RH8sebC6g=; b=Zh6yAWRk2IYiW2mKuKJ/FR6tzbRw5g8vWFXn6uYxd/xCj0knqXl3mdhgmDTr+eCP/D /AhY/Y36l7owJzb7jj01qiZIuYVfvngXJ0n4TZU+O/3mcpdLXk+L6uV4g8Az8i8TCZSw RwXJ0L6rp8DsabE6MfeK27qc+E3LBw3FP5SwjxSzIWpFEJz4ddWHHDfEhPJ2WqmlsSZM l50GHAepO+MmZtRsuTafB+Mn9z48YleeIcHQv8iy0VTEgvKjphUMR3NmASAz8yzWIfaB 8zjuxTy9pmS2TWPf7J8yGsgLQiPp9ciuVewpBLQbJz8SYAbIX7F3R+L9KTQEkrc70uRo 6Xzw== X-Gm-Message-State: AOAM530HrkoTP2WOWDH4cTN8TqwJOCI8ygfYavqCe7DtJnIlvMwmR37Q N4/oVhNFxigq2CmkzJZxY+tTLP47SOE= X-Google-Smtp-Source: ABdhPJw1WLaJt1wz9itOgfj7pPjBlw2xXYrT6jt9xeyZPyALNNRSlFuN+TayMfobCW23vb/d4MMU2OIBnl0= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:902:76cb:b0:15e:f795:bf5e with SMTP id j11-20020a17090276cb00b0015ef795bf5emr1930290plt.39.1652394444060; Thu, 12 May 2022 15:27:24 -0700 (PDT) Reply-To: Sean Christopherson Date: Thu, 12 May 2022 22:27:16 +0000 In-Reply-To: <20220512222716.4112548-1-seanjc@google.com> Message-Id: <20220512222716.4112548-4-seanjc@google.com> Mime-Version: 1.0 References: <20220512222716.4112548-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.550.gb090851708-goog Subject: [PATCH 3/3] KVM: x86: Add helpers to identify CTL and STATUS MCi MSRs From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jue Wang Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add helpers to identify CTL (control) and STATUS MCi MSR types instead of open coding the checks using the offset. Using the offset is perfectly safe, but unintuitive, as understanding what the code does requires knowing that the offset calcuation will not affect the lower three bits. Opportunistically comment the STATUS logic to save readers a trip to Intel's SDM or AMD's APM to understand the "data !=3D 0" check. No functional change intended. Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson --- arch/x86/kvm/x86.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 7e685ea9882b..b61c5def0bfc 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3188,6 +3188,16 @@ static void kvmclock_sync_fn(struct work_struct *wor= k) KVMCLOCK_SYNC_PERIOD); } =20 +/* These helpers are safe iff @msr is known to be an MCx bank MSR. */ +static bool is_mci_control_msr(u32 msr) +{ + return (msr & 3) =3D=3D 0; +} +static bool is_mci_status_msr(u32 msr) +{ + return (msr & 3) =3D=3D 1; +} + /* * On AMD, HWCR[McStatusWrEn] controls whether setting MCi_STATUS results = in #GP. */ @@ -3225,9 +3235,6 @@ static int set_msr_mce(struct kvm_vcpu *vcpu, struct = msr_data *msr_info) if (msr > last_msr) return 1; =20 - offset =3D array_index_nospec(msr - MSR_IA32_MC0_CTL, - last_msr + 1 - MSR_IA32_MC0_CTL); - /* * Only 0 or all 1s can be written to IA32_MCi_CTL, all other * values are architecturally undefined. But, some Linux @@ -3235,15 +3242,21 @@ static int set_msr_mce(struct kvm_vcpu *vcpu, struc= t msr_data *msr_info) * issue on AMD K8s, allow bit 10 to be clear when setting all * other bits in order to avoid an uncaught #GP in the guest. */ - if ((offset & 0x3) =3D=3D 0 && + if (is_mci_control_msr(msr) && data !=3D 0 && (data | (1 << 10)) !=3D ~(u64)0) return 1; =20 - /* MCi_STATUS */ - if (!msr_info->host_initiated && (offset & 0x3) =3D=3D 1 && + /* + * All CPUs allow writing 0 to MCi_STATUS MSRs to clear the MSR. + * AMD-based CPUs allow non-zero values, but if and only if + * HWCR[McStatusWrEn] is set. + */ + if (!msr_info->host_initiated && is_mci_status_msr(msr) && data !=3D 0 && !can_set_mci_status(vcpu)) return 1; =20 + offset =3D array_index_nospec(msr - MSR_IA32_MC0_CTL, + last_msr + 1 - MSR_IA32_MC0_CTL); vcpu->arch.mce_banks[offset] =3D data; break; default: --=20 2.36.0.550.gb090851708-goog