Message ID | 20230808233132.2499764-1-seanjc@google.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c44e:0:b0:3f2:4152:657d with SMTP id w14csp2491124vqr; Tue, 8 Aug 2023 18:04:59 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFAnDrGQBmlqxWQwU3Mjb2b1WQpECZnjG439TNafoJhy9oVWh/KHoJEcjjPHcLx7gk0KKlV X-Received: by 2002:a17:906:8471:b0:99b:d4a0:1322 with SMTP id hx17-20020a170906847100b0099bd4a01322mr903864ejc.41.1691543099536; Tue, 08 Aug 2023 18:04:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691543099; cv=none; d=google.com; s=arc-20160816; b=0U/WUJW7CCbiVdZQidfuLuZ36RnPDJcf8RmrOPGXBk3ODbHWrhDD46RFYhocjA9z0m X05+Ysb5nkeABHcUc1ybYUtOX5gNxTe0bVte7pBjIZaR300KezcFb/gPO/GbSH7z0nKN 7Q+Xsm2iAvqdfrjwbIis1KR1kHfU47xsAG0wAP7yXoy2+pN24HlCHQLzh42TlHT+JIed KQI9HA6SFGmdVP0R/+pY4aMpCo0lN7qu9Q4MuUBea+/wt7ccp4d9qGUYTcINnwQQPql9 c365vO6sPBttGtNpEzPiaqMJrgxnSWyxPlVmP7nK2Tq7zl2XzMmRnmMKhr77u3to3u7P n4zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :reply-to:dkim-signature; bh=vCWDiaOK6oBwC1N/JsFyjgQDQveeX0EIpcqjh3sU/K4=; fh=+ELRAU7IOTw9hBstKSPZFpPSQQ24hjx/lmc1fLMNzO0=; b=pljwl0QgvOCBOWyHaCK4vZ4ZYYOGnIS4G/sNeFs6EPpbaeFM+NH7gJynE/C655A6Ld dt+DSXs0UPzFTWUSlioCkI+ASJERKZoe27DFGAWWcbxjvZG/5pb+RpMB0TgOBp1kiG7v rqhF9SC11UzX82eU2Izdabn4S307eE5x0pNhKhn4QLC/a0vTJnyYtshnWubk2Na3aJh7 GHYWgR2iGEf8BSZ6U/Ew3NgYxW5eRkEznyyxKrzivQkpoIf/AnMwd3d1nZGmP2YPetwW glPCc8oEUjsWYn5c5cMG7/J1OV2gSxmSwfJ+oRQCwPpzNwV19L0pzyoZMKpoB3oDLe+h k7Rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=Inx83viY; 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=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gu6-20020a170906f28600b00993b3881ecdsi8702844ejb.687.2023.08.08.18.04.36; Tue, 08 Aug 2023 18:04:59 -0700 (PDT) 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=@google.com header.s=20221208 header.b=Inx83viY; 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=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230226AbjHHXbg (ORCPT <rfc822;aaronkmseo@gmail.com> + 99 others); Tue, 8 Aug 2023 19:31:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229643AbjHHXbf (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 8 Aug 2023 19:31:35 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B2321BC7 for <linux-kernel@vger.kernel.org>; Tue, 8 Aug 2023 16:31:35 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id 41be03b00d2f7-53f6e19f814so3928877a12.3 for <linux-kernel@vger.kernel.org>; Tue, 08 Aug 2023 16:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691537495; x=1692142295; h=cc:to:from:subject:message-id:mime-version:date:reply-to:from:to:cc :subject:date:message-id:reply-to; bh=vCWDiaOK6oBwC1N/JsFyjgQDQveeX0EIpcqjh3sU/K4=; b=Inx83viYix2Se7Jb1ETomI+W1Zw6vezUhCgHSmdSAr8poGqBpfWExnh5zNfCaAJqXx Y0JBaPAPbfQLVyRAdZfMDAQ/y4UvdjF6bt0IlXWo5+AdxOZ17Mn4ODYEL4gKctWoF/iy rj9ApP11OCYcfsub/g94LJVrRjTnyl2LCnM2B+PJ9XviM5EWnO5fz0UAOBGGiZYek0SJ ZPJCjyNePTJiz2bnoiyUDkEYdeGPRraYeewj9cXixHHQlniuajeh4PF6gO03hIZQ4+9U APYuojQpT0AOdjAdd+GveUVCw3KTcfjkfTJ6+1777gSre8pX/ZW2MJ4pw7k4M3uEbfCK uqtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691537495; x=1692142295; h=cc:to:from:subject:message-id:mime-version:date:reply-to :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vCWDiaOK6oBwC1N/JsFyjgQDQveeX0EIpcqjh3sU/K4=; b=fgUo1b9ryx0V6lb/Zm4ONQSw286BvritYeBc3zG/DGSm2BJN23WvlGic5Y1tbmwSjs nY5clSQX40gT5a6/j1GaRpEkiTSVWpyTxEkfanaLraVq+uwwxpV3Zyb38GdGiw9EHFtm 9+AqUn0td1YMZAPLILvB6FY3zZ07apDuOogUm0XNDlyPd07ll8+BSqfgx4E6vLymcJ/U xiMJxJzRRjCRNRawm67D7lZ4fbcYR5VIslWwgoXKKxyQhxt7giUlETKytmRZrrDAllYd ur1GU26sRw3hI6SYwZeGPJuIoFQ21PlzL5PCg6jkzTJ95rtebjZ0dv1wBiuHhelBRDdz u0MA== X-Gm-Message-State: AOJu0Yz62J7ZHYoy7y1UTOLIxnedmi5xMzr1hCKbWZfjwV1xpBssPZZQ DG2tL9EpatINeAwMHoK3N3922l2bouQ= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:d485:b0:1b7:c803:4818 with SMTP id c5-20020a170902d48500b001b7c8034818mr22359plg.0.1691537494674; Tue, 08 Aug 2023 16:31:34 -0700 (PDT) Reply-To: Sean Christopherson <seanjc@google.com> Date: Tue, 8 Aug 2023 16:31:30 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.41.0.640.ga95def55d0-goog Message-ID: <20230808233132.2499764-1-seanjc@google.com> Subject: [PATCH 0/2] KVM: SVM: Set pCPU during IRTE update if vCPU is running From: Sean Christopherson <seanjc@google.com> To: Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, "dengqiao . joey" <dengqiao.joey@bytedance.com>, Alejandro Jimenez <alejandro.j.jimenez@oracle.com>, Joao Martins <joao.m.martins@oracle.com>, Maxim Levitsky <mlevitsk@redhat.com>, Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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: INBOX X-GMAIL-THRID: 1773711497146080393 X-GMAIL-MSGID: 1773711497146080393 |
Series |
KVM: SVM: Set pCPU during IRTE update if vCPU is running
|
|
Message
Sean Christopherson
Aug. 8, 2023, 11:31 p.m. UTC
Fix a bug where KVM doesn't set the pCPU affinity for running vCPUs when updating IRTE routing. Not setting the pCPU means the IOMMU will signal the wrong pCPU's doorbell until the vCPU goes through a put+load cycle. I waffled for far too long between making this one patch or two. Moving the lock doesn't make all that much sense as a standalone patch, but in the end, I decided that isolating the locking change would be useful in the unlikely event that it breaks something. If anyone feels strongly about making this a single patch, I have no objection to squashing these together. Sean Christopherson (2): KVM: SVM: Take and hold ir_list_lock when updating vCPU's Physical ID entry KVM: SVM: Set target pCPU during IRTE update if target vCPU is running arch/x86/kvm/svm/avic.c | 59 +++++++++++++++++++++++++++++++++++------ 1 file changed, 51 insertions(+), 8 deletions(-) base-commit: 240f736891887939571854bd6d734b6c9291f22e
Comments
On 09/08/2023 00:31, Sean Christopherson wrote: > Fix a bug where KVM doesn't set the pCPU affinity for running vCPUs when > updating IRTE routing. Not setting the pCPU means the IOMMU will signal > the wrong pCPU's doorbell until the vCPU goes through a put+load cycle. > Or also framed as an inefficiency that we depend on the GALog (for a running vCPU) for interrupt delivery until the put+load cycle happens. I don't think I ever reproduced the missed interrupt case in our stress testing. > I waffled for far too long between making this one patch or two. Moving > the lock doesn't make all that much sense as a standalone patch, but in the > end, I decided that isolating the locking change would be useful in the > unlikely event that it breaks something. If anyone feels strongly about > making this a single patch, I have no objection to squashing these together. > IMHO, as two patches looks better; For what is worth: Reviewed-by: Joao Martins <joao.m.martins@oracle.com> I think Alejandro had reported his testing as successful here: https://lore.kernel.org/kvm/caefe41b-2736-3df9-b5cd-b81fc4c30ff0@oracle.com/ OTOH, he didn't give the Tested-by explicitly
On Wed, Aug 09, 2023, Joao Martins wrote: > On 09/08/2023 00:31, Sean Christopherson wrote: > > Fix a bug where KVM doesn't set the pCPU affinity for running vCPUs when > > updating IRTE routing. Not setting the pCPU means the IOMMU will signal > > the wrong pCPU's doorbell until the vCPU goes through a put+load cycle. > > > > Or also framed as an inefficiency that we depend on the GALog (for a running > vCPU) for interrupt delivery until the put+load cycle happens. I don't think I > ever reproduced the missed interrupt case in our stress testing. Ah, I'll reword the changelog in patch 2 if this only delays the interrupt instead of dropping it entirely. > > I waffled for far too long between making this one patch or two. Moving > > the lock doesn't make all that much sense as a standalone patch, but in the > > end, I decided that isolating the locking change would be useful in the > > unlikely event that it breaks something. If anyone feels strongly about > > making this a single patch, I have no objection to squashing these together. > > > IMHO, as two patches looks better; > > For what is worth: > > Reviewed-by: Joao Martins <joao.m.martins@oracle.com> > > I think Alejandro had reported his testing as successful here: > > https://lore.kernel.org/kvm/caefe41b-2736-3df9-b5cd-b81fc4c30ff0@oracle.com/ > > OTOH, he didn't give the Tested-by explicitly Yeah, I almost asked for a Tested-by, but figured it would be just as easy to post the patches.
On 8/9/23 10:23, Sean Christopherson wrote: > On Wed, Aug 09, 2023, Joao Martins wrote: >> On 09/08/2023 00:31, Sean Christopherson wrote: >>> Fix a bug where KVM doesn't set the pCPU affinity for running vCPUs when >>> updating IRTE routing. Not setting the pCPU means the IOMMU will signal >>> the wrong pCPU's doorbell until the vCPU goes through a put+load cycle. >>> >> >> Or also framed as an inefficiency that we depend on the GALog (for a running >> vCPU) for interrupt delivery until the put+load cycle happens. I don't think I >> ever reproduced the missed interrupt case in our stress testing. Right, I was never able to see any dropped interrupts when testing the baseline host kernel with "idle=poll" on my guest. Though I didn't reproduce Dengqiao's setup exactly e.g. they imply using isolcpus in the host kernel params. > > Ah, I'll reword the changelog in patch 2 if this only delays the interrupt instead > of dropping it entirely. > >>> I waffled for far too long between making this one patch or two. Moving >>> the lock doesn't make all that much sense as a standalone patch, but in the >>> end, I decided that isolating the locking change would be useful in the >>> unlikely event that it breaks something. If anyone feels strongly about >>> making this a single patch, I have no objection to squashing these together. >>> >> IMHO, as two patches looks better; >> >> For what is worth: >> >> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> >> >> I think Alejandro had reported his testing as successful here: >> >> https://lore.kernel.org/kvm/caefe41b-2736-3df9-b5cd-b81fc4c30ff0@oracle.com/ >> >> OTOH, he didn't give the Tested-by explicitly > > Yeah, I almost asked for a Tested-by, but figured it would be just as easy to > post the patches. I was hoping to find more time to test with other configs (i.e. more closely matching the original environment). That being said, besides the positive results from the validation script mentioned earlier, I have been using the patched kernel to launch guests in my setup for quite some time now without encountering any issues. From my side: Tested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>