From nobody Sun Feb 8 12:36:40 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 C74E9C53210 for ; Fri, 6 Jan 2023 01:13:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236837AbjAFBNj (ORCPT ); Thu, 5 Jan 2023 20:13:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236747AbjAFBNR (ORCPT ); Thu, 5 Jan 2023 20:13:17 -0500 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 6585B71FFF for ; Thu, 5 Jan 2023 17:13:16 -0800 (PST) Received: by mail-pj1-x104a.google.com with SMTP id z4-20020a17090ab10400b002195a146546so2085980pjq.9 for ; Thu, 05 Jan 2023 17:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=O/yK9t38GUx7xAC8BnI1OsbEu+wskTkGWc8pHxjCI1M=; b=XC1QRawbtqcuGIvkyZGXfO4dWvKusbHvx7Ceuk2s9f1EDWyGwTXKxmEF/7/RoIyTQl 83ZnpCeWlNJvN0EszGtRNrqExAEYtasediUZNG+ehmTQiMkhoIjKnQhWX+hIoogU83y5 xCHw6f+G8TqjvtBXoV0fhoUCuqOQwLxYgvCx9gO1Yv6C08Kbd4rG0qe2BBVTMw5geDsF YPuiC4gu1ZtesL5MNl+S7dkrBrISA94kw1YYFc7EnChdP1MFnbPrSXyA/2qtyEzjSHcX TfB3JBGQsJtAUeyHu6mN2XX8OUtEzSnJzI4Mv2SeSy55WQ4uXyfv6rzWDVYiIitmKYhS xNBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=O/yK9t38GUx7xAC8BnI1OsbEu+wskTkGWc8pHxjCI1M=; b=7/rzBzGPaR6a+u6jsRU4g0NWZhPtzBdclwvvwUHJVEfxHXsd/XC2o7Syhmd5nAyNJr hMSUpzIeDY2BtEOW3qnF1EfGnnFwlxRVkJhQNWG93VTRDAWdIkbsjVQUcKIJHAe/4/wh j/8iy0FZPSFoDQB9aI+6g5TgZXW9jIx2VtWGkHeZ2G1B2O6bkDP+18jYyus13NW8w5LP QE7QgjBSlTr3lnT8HdkMQplB0iC5b8HQHhuQs0od4S38rArOdQhbNso2Cq9QEvQdhUAY FNJ3f7sWeZ13TXWRlC7wkgvLm5EHq/G0osYx+clYyLSMJLVaX+wMOFbToOzahAWXByFO rDVA== X-Gm-Message-State: AFqh2kqyEbdWGvZYl6p8A6pHRQf4b9NmRx6pxmuJqQuFv6AGrlG752Ui 8GVjB9/BBb3+fZbIMv+5/6vgjKIHLwI= X-Google-Smtp-Source: AMrXdXsgyShRZdisFO/emIevEQAlXI6bCsWIdDxxcLZDMha/PDisLDjL6Hp3/hVg7Q3rpOuUTqoyPIwEZ98= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:40c8:b0:189:7a15:134b with SMTP id t8-20020a17090340c800b001897a15134bmr2814877pld.143.1672967595896; Thu, 05 Jan 2023 17:13:15 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:34 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-2-seanjc@google.com> Subject: [PATCH v5 01/33] KVM: x86: Blindly get current x2APIC reg value on "nodecode write" traps From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When emulating a x2APIC write in response to an APICv/AVIC trap, get the the written value from the vAPIC page without checking that reads are allowed for the target register. AVIC can generate trap-like VM-Exits on writes to EOI, and so KVM needs to get the written value from the backing page without running afoul of EOI's write-only behavior. Alternatively, EOI could be special cased to always write '0', e.g. so that the sanity check could be preserved, but x2APIC on AMD is actually supposed to disallow non-zero writes (not emulated by KVM), and the sanity check was a byproduct of how the KVM code was written, i.e. wasn't added to guard against anything in particular. Fixes: 70c8327c11c6 ("KVM: x86: Bug the VM if an accelerated x2APIC trap oc= curs on a "bad" reg") Fixes: 1bd9dfec9fd4 ("KVM: x86: Do not block APIC write for non ICR registe= rs") Reported-by: Alejandro Jimenez Cc: stable@vger.kernel.org Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson --- arch/x86/kvm/lapic.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 4efdb4a4d72c..5c0f93fc073a 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2284,23 +2284,18 @@ void kvm_apic_write_nodecode(struct kvm_vcpu *vcpu,= u32 offset) struct kvm_lapic *apic =3D vcpu->arch.apic; u64 val; =20 - if (apic_x2apic_mode(apic)) { - if (KVM_BUG_ON(kvm_lapic_msr_read(apic, offset, &val), vcpu->kvm)) - return; - } else { - val =3D kvm_lapic_get_reg(apic, offset); - } - /* * ICR is a single 64-bit register when x2APIC is enabled. For legacy * xAPIC, ICR writes need to go down the common (slightly slower) path * to get the upper half from ICR2. */ if (apic_x2apic_mode(apic) && offset =3D=3D APIC_ICR) { + val =3D kvm_lapic_get_reg64(apic, APIC_ICR); kvm_apic_send_ipi(apic, (u32)val, (u32)(val >> 32)); trace_kvm_apic_write(APIC_ICR, val); } else { /* TODO: optimize to just emulate side effect w/o one more write */ + val =3D kvm_lapic_get_reg(apic, offset); kvm_lapic_reg_write(apic, offset, (u32)val); } } --=20 2.39.0.314.g84b9a713c41-goog