Message ID | 20221114202037.254176-1-gedwards@ddn.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2346873wru; Mon, 14 Nov 2022 12:23:19 -0800 (PST) X-Google-Smtp-Source: AA0mqf6gNWeTKql8xIJo4BZPKrITCRVcLwIRV5HkgbO5xPw1wthvMp5SbgXThAINYG2hbGUN26zc X-Received: by 2002:aa7:8a4a:0:b0:562:e571:3f0e with SMTP id n10-20020aa78a4a000000b00562e5713f0emr15022119pfa.72.1668457399254; Mon, 14 Nov 2022 12:23:19 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1668457399; cv=pass; d=google.com; s=arc-20160816; b=nJkFxiFFyICho/1LA+UTiqy3v+b+uoTBtIx+goLretTrUn89CsT7SPb3XvaqqC9a4O PM1a8gYKxf1qZHbjPOiHaScn2IDXsByzEx7yeDSAyY4ADmt0c6ivzYyI/0e/D4gqCshn HIpcEaHtfw4GKdpsSN2TIDY0p9hH7JOB8Eb8AOwJ3CJyZw/r3FIHOlxUKoduODrfoE14 +wmmHChJJi7rwyxmOOhdes7GHphc3jl7KEziQvpfX2NYyQuY2MlvHiGLmEEu1/VAo5fN vhkeD2umWDk6zmvPpuMMIyjdb/xs9LOzHr+Fl+wxwcDoY5F/0CqJFxKo7oikie5E/L4x DUFQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-disposition:message-id :subject:cc:to:from:date:dkim-signature; bh=QfUXSP07zqs+SkXBFMXbdVRUWpvfh/LohaAi0IDUIw4=; b=NhXY+sB0/LSm6DjJ45KC/9xqtVea9ozZTT9myTsgpaAqCEtmCuHdZxiFhuVX/QLGc8 JWl7WNI3HKRwdt3jdgU3ZPzTAemMJk7x1LzbsLqIAqRHWMDq1vawj653rEVaYU2XH/42 K9DdWbVpr0nWJB6b//s6pbxMO6aPmhPudVFJskgllnzIufZr3YtfNb0nTTTt7+eAcq8K Oerkm9wMm1/BsoLXXNPuavZTX/UwOz+hGnYLH+MffWmWrQdAfR6M2dRWXPv2zVa9IDP9 pdmvVAZD2xhJnjxphrzORZCuodRBO3WFHbCJiZNtrcfZXGke9KWd5i4h17BDMgyQIVvb 29Bw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@ddn.com header.s=selector2 header.b=wp5uTRNx; arc=pass (i=1 spf=pass spfdomain=ddn.com dkim=pass dkdomain=ddn.com dmarc=pass fromdomain=ddn.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ddn.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i6-20020a655b86000000b00470422203cesi10223995pgr.159.2022.11.14.12.23.04; Mon, 14 Nov 2022 12:23:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ddn.com header.s=selector2 header.b=wp5uTRNx; arc=pass (i=1 spf=pass spfdomain=ddn.com dkim=pass dkdomain=ddn.com dmarc=pass fromdomain=ddn.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ddn.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237603AbiKNUVC (ORCPT <rfc822;zwp10758@gmail.com> + 99 others); Mon, 14 Nov 2022 15:21:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237593AbiKNUVA (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 14 Nov 2022 15:21:00 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2059.outbound.protection.outlook.com [40.107.94.59]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63BC12713; Mon, 14 Nov 2022 12:20:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MutY0FtJDzEOHIMAwlZ1zPjRF8JKCS32XRRqq8iWOxzDtUWScW4ofQxMu8pC7DbLPbDUnitnTDPtYMXnFRA4wReKJMqilCE4tyA5T3WkqVnwBFVZVNghhDuvfjSCo5mKdhsQOS7aWL7H7i0dFKGjU5ElqM14vv7+OLB7XnJ3jElpKvJf2KaRhE6Qx5FSRCAgE0LJjGxeRRBC5StnNhyVliCT9c/+Mf0uxifpudMP5suVNLt98IK12fqNGwX9ahEJ0oU++WCbTpogp6aupWTPLuVcVGNuoJNXbe3VAJWqR08an7YzeVIeSIsk33Y6/jjFwGaBdNII7p7puJlDmO+IDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QfUXSP07zqs+SkXBFMXbdVRUWpvfh/LohaAi0IDUIw4=; b=hwrr8UPuK4X637skhOS2AfoRp4gVArCH9/lsn+TSOe5bnG9CCoeVHof2qDmdWlWQC0T63W4zBNtpP5eixbccNClU5HP54gB24U5Ker4m5vTSBn4Pid4mKNukGf9ZP98mmbDXjz7StU4CZgZeT154JQ4WK6JzqjqTDwI53dYlXaUf3qJ3/pnK57vS96DQqNfydWF4YBDv+GJPYi13fXVLl9vgd1oqwkxubLm5PxFLWtaE3tWHaCI9R0p13QuNDV0gJq+ypbsu1ZZgdQOkJHo/tbHEfJjhM+ZzCp+bT4B9zB/owePF+EjnqboQ4G1qP00kIYZdlFEdGOxc9W23gAqXrw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ddn.com; dmarc=pass action=none header.from=ddn.com; dkim=pass header.d=ddn.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ddn.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QfUXSP07zqs+SkXBFMXbdVRUWpvfh/LohaAi0IDUIw4=; b=wp5uTRNxukQ+N/ZvkVWzn+4SS+ekH7CF0Sz4QegmapwJpG47neJba+DdHZPG0vmLi7bSKFjflfu1yCkrkT0oAC5EisfrOjGSXs8ASURAwisbHp5hG054DFczSRfpkXxTIAZCiVC3rec7oIS23pkWpRcCrHTJOrRVrtYQhPyvQ4A= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ddn.com; Received: from MN0PR19MB6407.namprd19.prod.outlook.com (2603:10b6:208:3c0::20) by PH8PR19MB6835.namprd19.prod.outlook.com (2603:10b6:510:1be::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.17; Mon, 14 Nov 2022 20:20:56 +0000 Received: from MN0PR19MB6407.namprd19.prod.outlook.com ([fe80::db4d:6649:2aef:bae9]) by MN0PR19MB6407.namprd19.prod.outlook.com ([fe80::db4d:6649:2aef:bae9%5]) with mapi id 15.20.5813.017; Mon, 14 Nov 2022 20:20:56 +0000 Date: Mon, 14 Nov 2022 13:20:55 -0700 From: Greg Edwards <gedwards@ddn.com> To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Paolo Bonzini <pbonzini@redhat.com>, Sean Christopherson <seanjc@google.com>, Maxim Levitsky <mlevitsk@redhat.com>, Greg Edwards <gedwards@ddn.com> Subject: [PATCH] KVM: x86: Allow APICv APIC ID inhibit to be cleared on legacy kernels Message-ID: <20221114202037.254176-1-gedwards@ddn.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailer: git-send-email 2.38.1 X-ClientProxiedBy: CH0PR04CA0097.namprd04.prod.outlook.com (2603:10b6:610:75::12) To MN0PR19MB6407.namprd19.prod.outlook.com (2603:10b6:208:3c0::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN0PR19MB6407:EE_|PH8PR19MB6835:EE_ X-MS-Office365-Filtering-Correlation-Id: 246643af-c8d7-45b9-8081-08dac67dbcba X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: voGaK9j8Vc5vusOg5liI5/FyF0w36KGdulMfTOYiNUX/OKFKWV1FK48BNrNO7Io5aO+t1lgeb+SmOaBsV6FbWkOw0iSaGyYGSFpueVK7Gt4/7hteI2Zfkiz5UFiEE70tCI2r25MvJU1dA+aJuZMq6iyuiKrKtbPXze/XF7k9DMwEmJJUVaqkp00MmLVb2t2GGXwV7grE9dYKXXuIHTeIDEA5bvpUZuVGUhPrhmcSxIHsokz7wPUCZ23vULKJMQ/op6VZXg2ZRTZeGS8Zu0RmsPadAP8ApcxGll43YItSvlGPs2+IZniwuX5shwfkfyZjKOUv/YAy0SkMBmwKMwsbV+GNY+RJ4e2Wnb+CV8E3no8kTWgx7hM9X61+8hEmqRZWiF1EL8Rzowwf+lu/C7ED/y6lSq3LeHkDc4fJeycSSA/yqFafjyNuTTPiNGzlVehZaZRB8cAdtlkNiEUrprd7K+2FBBb7RaLNDomuVUPYXGvBrVU45042ZsKDzy/jxrI9Qxoji2m8lq2/Mh3Ejcb6lkuMqaqdSUv7djpe+6VoS8nmaRBsnPjplMD8dXAA3GGjDHiaCe4NiEwCSgRGi0YhnP6M/xGkHSu7kjCbronXuve/hHKThN4tDeJpOBdHTIxXFAM12pfKxkxfdHpmea2iMFDV6X8zA14G7WzT7YNfpGk1Y2nj7cyhPXGihvpyEwSwv0aonYouNWIdpomRHGG87h2GLutdiZAudvOWMOybQ+h/pNq0SK+NLs08finko9Sl X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN0PR19MB6407.namprd19.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(39850400004)(396003)(346002)(366004)(376002)(451199015)(2906002)(66476007)(66946007)(66556008)(41300700001)(2616005)(1076003)(38100700002)(316002)(54906003)(5660300002)(8936002)(4326008)(86362001)(8676002)(6506007)(6512007)(36756003)(186003)(478600001)(6486002)(83380400001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: gRHllQ/s9Fv4NCsKHfl9vsvvyL+AVlc8uU1zsDDx15I5/WewKdxidyZ0QPeyfd3qN4DSFtRGe0eIGmxQjmWcxspCJxnwb4y5aepBxR29GrmDTCok6sjIb/H7hPC5poV0NSoKjc4OL5zEX7moT3IgapOsLPFHSxVumJCOsXTt492b6IEa0hq54U7Q6AFVF2ieH43Mp1WFi6Y8GnH5aFx27aTfRK6F+z+nHAR9zEBoWx63FJKyECnfNe3OptOS6X1Dzh1CDBETakJUU+dSQcGJHDTCuiDVCHW+hUsdvz+nV2gQQCcyNz81eDTipvMV3FaNGTVqO1wfuYiMivpsAKURaFDXRUXlWD4qrzcjKzuX8lF7iDczSyOWQ632ai1GOdeJ8lnV14BKlZ7MbX+DQCjFG+1HnHX2CtvQxLQJvcmKzVgSab/XRparBeszhb55HuSrYJSsoX1nbvTypb7ziiu6gFLJysecrLmXpOcWsq3u2OkZoHEGBPUi130n43YV0H0lMOyRYLQ9OB7zgdMEjiS31+Vb/g9ZcDhlxWKUtDQTnreQ0DsoyCbloE//3rq1kNIBvnj1zXNE3TSVDGGEUxoLZo63t6zV/ZWIyaPjnnWbb7K9gIPnWIoIBZtg9Gox7YiwBRxWFY5OGmOPhk5cdXTS17Kt9QuLddfv00y/gbeT+9IdRTZQB4WWYRhMtbWRRfMak84o1m9WHO5fJSa9ss03vZq9dtIpovQ8/ZFoOD4aB39TkFT6u/j610Y9t4EbkMvoDaS1sE22AUn4ZJ2fFhHj/d+/MS599cOFfO3cHVJBpYx046z/vVkh5XPtTAaz+VMKG5AZ9JIkc60sJmgMS3tj2ZrFaiuj1Qsztu/k/R4imoE7dgt+5l4n4BbVihwlYtIiYZC2IjDokd3eRMnq0vOQr2AJnw2kuHomkVhI1xSV17raMFj7CNOlTrndQCQzV6SCD0q6/ziBcEyHSO6gE9V0zQ1RgzXOD/j+HQUSg2V1dAEg9YrYfdiVQo+pV+BH/Mk95P2bDiw5z3XTY/1+NtyMC7ZQKxNluDEEI06OoZ8hphh0w2lmiWo6KAWwtIGJzoWVXO4y4HSWjLm08BrjvWSnqxbC0PpY27L7xxAgyNDwMUPHggts98OJ/IIf4gG05mC3Opid+naM5efpmO7eh2wGfNz9UWq9QLA1nca6BRz0n4M+V/WgrNEuOUn3y0hmPEVCM/Pm38fGKHE/B0HJmJEBCMFFktUULv7y0YdIdqrNuNfyfxBR43zpySruBe6AxVPzvLkhYczSJgEiXduKjD2LUZdbiY4ODZa6KpiOgp9GOE1Fq/MZ7yAKkWjeHPpnwG8cfGU9cZrRU3N4rBlyk1HEh3K5BUlEKQAvbS6vo9xjA2OnfEN8a8JdT/XT+S8Jkv/br1eHgaSNeP/cSMUrUSNdm8MPrgP3/JUCNpgKN5vB9Xw3yTdnx6ScN4PZbaTl+1Eu2k+OWxDr235lhYrPHUHTW899SlbDYpMaWNqA06cKllvqO1e5djO9XQ4tHQWTIdoLaCJa8vYnPWQu+z5qDj3M3NFC8Aj5GxvPNW/zmdicV5dOoQWHbEkq1RPqzF3MtaKVLH3Dtujo61gS2ogSP4BIhw== X-OriginatorOrg: ddn.com X-MS-Exchange-CrossTenant-Network-Message-Id: 246643af-c8d7-45b9-8081-08dac67dbcba X-MS-Exchange-CrossTenant-AuthSource: MN0PR19MB6407.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2022 20:20:56.6678 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 753b6e26-6fd3-43e6-8248-3f1735d59bb4 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: qFCkLIdkFh5/Rk+2S7JEefHa6VMUYvBkMvg74mPFom7Nt3gLlvEUrJnhzbm01EnDZ2NIeykjbuJRm65iZprPGw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR19MB6835 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749504385725294779?= X-GMAIL-MSGID: =?utf-8?q?1749504385725294779?= |
Series |
KVM: x86: Allow APICv APIC ID inhibit to be cleared on legacy kernels
|
|
Commit Message
Greg Edwards
Nov. 14, 2022, 8:20 p.m. UTC
Legacy kernels prior to commit 4399c03c6780 ("x86/apic: Remove
verify_local_APIC()") write the xAPIC ID of the boot CPU twice to verify
a functioning local APIC. This results in APIC acceleration inhibited
on these kernels for reason APICV_INHIBIT_REASON_APIC_ID_MODIFIED.
Allow the APICV_INHIBIT_REASON_APIC_ID_MODIFIED inhibit reason to be
cleared if/when the xAPIC ID is set back to the expected vcpu_id value.
This occurs on the second xAPIC ID write in verify_local_APIC().
Fixes: 3743c2f02517 ("KVM: x86: inhibit APICv/AVIC on changes to APIC ID or APIC base")
Signed-off-by: Greg Edwards <gedwards@ddn.com>
---
arch/x86/kvm/lapic.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Comments
On Mon, Nov 14, 2022, Greg Edwards wrote: > Legacy kernels prior to commit 4399c03c6780 ("x86/apic: Remove > verify_local_APIC()") write the xAPIC ID of the boot CPU twice to verify > a functioning local APIC. This results in APIC acceleration inhibited > on these kernels for reason APICV_INHIBIT_REASON_APIC_ID_MODIFIED. > > Allow the APICV_INHIBIT_REASON_APIC_ID_MODIFIED inhibit reason to be > cleared if/when the xAPIC ID is set back to the expected vcpu_id value. > This occurs on the second xAPIC ID write in verify_local_APIC(). > > Fixes: 3743c2f02517 ("KVM: x86: inhibit APICv/AVIC on changes to APIC ID or APIC base") > Signed-off-by: Greg Edwards <gedwards@ddn.com> > --- > arch/x86/kvm/lapic.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > index d7639d126e6c..4064d0af094d 100644 > --- a/arch/x86/kvm/lapic.c > +++ b/arch/x86/kvm/lapic.c > @@ -2075,8 +2075,13 @@ static void kvm_lapic_xapic_id_updated(struct kvm_lapic *apic) > if (KVM_BUG_ON(apic_x2apic_mode(apic), kvm)) > return; > > - if (kvm_xapic_id(apic) == apic->vcpu->vcpu_id) > + if (kvm_xapic_id(apic) == apic->vcpu->vcpu_id) { > + /* Legacy kernels prior to 4399c03c6780 write APIC ID twice. */ > + if (!kvm_apicv_activated(kvm)) > + kvm_clear_apicv_inhibit(kvm, > + APICV_INHIBIT_REASON_APIC_ID_MODIFIED); This sadly doesn't work because the inhibit is per-VM, i.e. will do the wrong thing if there are still vCPU's with different APIC IDs. Does skipping the check if the APIC is disabled help[*]? At a glance, I can't tell if the APIC is enabled/disabled at that point in time. It's not a true fix, but it's a lot easier to backport if it remedies the issue. For a proper fix, this entire path should be moved to kvm_recalculate_apic_map() so that can can safely toggle the inhibit, e.g. the recalc helper already deals with multiple vCPUs changing their APIC state in parallel. I don't think the fix will be too difficult to craft such that it's backport friendly, but it would need to be slotted into the series containing the aforementioned fix. [*] https://lore.kernel.org/all/20221001005915.2041642-6-seanjc@google.com --- arch/x86/kvm/lapic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 5de1c7aa1ce9..67260f7ce43a 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2072,6 +2072,9 @@ static void kvm_lapic_xapic_id_updated(struct kvm_lapic *apic) { struct kvm *kvm = apic->vcpu->kvm; + if (!kvm_apic_hw_enabled(apic)) + return; + if (KVM_BUG_ON(apic_x2apic_mode(apic), kvm)) return;
On Mon, Nov 14, 2022 at 09:30:18PM +0000, Sean Christopherson wrote: > On Mon, Nov 14, 2022, Greg Edwards wrote: >> Legacy kernels prior to commit 4399c03c6780 ("x86/apic: Remove >> verify_local_APIC()") write the xAPIC ID of the boot CPU twice to verify >> a functioning local APIC. This results in APIC acceleration inhibited >> on these kernels for reason APICV_INHIBIT_REASON_APIC_ID_MODIFIED. >> >> Allow the APICV_INHIBIT_REASON_APIC_ID_MODIFIED inhibit reason to be >> cleared if/when the xAPIC ID is set back to the expected vcpu_id value. >> This occurs on the second xAPIC ID write in verify_local_APIC(). >> >> Fixes: 3743c2f02517 ("KVM: x86: inhibit APICv/AVIC on changes to APIC ID or APIC base") >> Signed-off-by: Greg Edwards <gedwards@ddn.com> >> --- >> arch/x86/kvm/lapic.c | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c >> index d7639d126e6c..4064d0af094d 100644 >> --- a/arch/x86/kvm/lapic.c >> +++ b/arch/x86/kvm/lapic.c >> @@ -2075,8 +2075,13 @@ static void kvm_lapic_xapic_id_updated(struct kvm_lapic *apic) >> if (KVM_BUG_ON(apic_x2apic_mode(apic), kvm)) >> return; >> >> - if (kvm_xapic_id(apic) == apic->vcpu->vcpu_id) >> + if (kvm_xapic_id(apic) == apic->vcpu->vcpu_id) { >> + /* Legacy kernels prior to 4399c03c6780 write APIC ID twice. */ >> + if (!kvm_apicv_activated(kvm)) >> + kvm_clear_apicv_inhibit(kvm, >> + APICV_INHIBIT_REASON_APIC_ID_MODIFIED); > > This sadly doesn't work because the inhibit is per-VM, i.e. will do the wrong > thing if there are still vCPU's with different APIC IDs. That is true. Thanks for pointing that out. > Does skipping the check if the APIC is disabled help[*]? At a glance, I can't > tell if the APIC is enabled/disabled at that point in time. It's not a true fix, > but it's a lot easier to backport if it remedies the issue. It does not. I did find your patch series when I started investigating this, but the behavior was the same on that series. > For a proper fix, this entire path should be moved to kvm_recalculate_apic_map() > so that can can safely toggle the inhibit, e.g. the recalc helper already deals > with multiple vCPUs changing their APIC state in parallel. I don't think the fix > will be too difficult to craft such that it's backport friendly, but it would need > to be slotted into the series containing the aforementioned fix. Thank you for the suggestion. I will take a look, and start from your series.
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index d7639d126e6c..4064d0af094d 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2075,8 +2075,13 @@ static void kvm_lapic_xapic_id_updated(struct kvm_lapic *apic) if (KVM_BUG_ON(apic_x2apic_mode(apic), kvm)) return; - if (kvm_xapic_id(apic) == apic->vcpu->vcpu_id) + if (kvm_xapic_id(apic) == apic->vcpu->vcpu_id) { + /* Legacy kernels prior to 4399c03c6780 write APIC ID twice. */ + if (!kvm_apicv_activated(kvm)) + kvm_clear_apicv_inhibit(kvm, + APICV_INHIBIT_REASON_APIC_ID_MODIFIED); return; + } kvm_set_apicv_inhibit(apic->vcpu->kvm, APICV_INHIBIT_REASON_APIC_ID_MODIFIED); }