public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, <kvm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Dongli Zhang <dongli.zhang@oracle.com>
Subject: Re: [PATCH v3 06/10] KVM: nVMX: Switch to vmcs01 to update SVI on-demand if L2 is active
Date: Wed, 31 Dec 2025 10:17:52 +0800	[thread overview]
Message-ID: <aVSH0GhLKqPcwPA5@intel.com> (raw)
In-Reply-To: <aVQ-MNmUa1fb83zH@google.com>

>> But I'm wondering whether KVM should update SVI on every VM-entry instead of
>> doing it on-demand (i.e., when vISR gets changed). We've encountered two
>> SVI-related bugs [1][2] that were difficult to debug. Preventing these issues
>> entirely seems worthwhile, and the overhead of always updating SVI during
>> VM-entry should be minimal since KVM already updates RVI (RVI and SVI are in
>> the the same VMCS field) in vmx_sync_irr_to_pir() when APICv is enabled.
>
>Hmm.  At first glance, I _really_ like this idea, but I'm leaning fairly strongly
>towards keeping .hwapic_isr_update().
>
>While small (~28 cycles on EMR), the runtime cost isn't zero, and it affects the
>fastpath.  And number of useful updates is comically small.  E.g. without a nested
>VM, AFAICT they basically never happen post-boot.  Even when running nested VMs,
>the number of useful update when running L1 hovers around ~0.001%.
>
>More importantly, KVM will carry most of the complexity related to vISR updates
>regardless of how KVM handles SVI because of the ISR caching for non-APICv
>systems.  So while I acknowledge that we've had some nasty bugs and 100% agree
>that squashing them entirely is _very_ enticing, I think those bugs were due to
>what were effectively two systemic flaws in KVM: (1) not aligning SVI with KVM's
>ISR caching code, and (2) the whole "defer updates to nested VM-Exit" mess.
>
>At the end of this series, both (1) and (2) are "solved".
 
Fair enough. Thanks for this explanation.

> Huh.  And now that I
>look at (1) again, the last patch is wrong (benignly wrong, but still wrong).
>The changelog says this:
>
>  First, it adds a call during kvm_lapic_reset(), but that's a glorified nop as
>  the ISR has already been zeroed.
>
>but that's simply not true.  There's already a call in kvm_lapic_reset().  So
>that patch can be amended with:

Yeah, the fix looks good to me.

>
>diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
>index 7be4d759884c..55a7a2be3a2e 100644
>--- a/arch/x86/kvm/lapic.c
>+++ b/arch/x86/kvm/lapic.c
>@@ -2907,10 +2907,8 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool init_event)
> 
>        vcpu->arch.pv_eoi.msr_val = 0;
>        apic_update_ppr(apic);
>-       if (apic->apicv_active) {
>+       if (apic->apicv_active)
>                kvm_x86_call(apicv_post_state_restore)(vcpu);
>-               kvm_x86_call(hwapic_isr_update)(vcpu, -1);
>-       }
> 
>        vcpu->arch.apic_arb_prio = 0;
>        vcpu->arch.apic_attention = 0;
>

  reply	other threads:[~2025-12-31  2:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-05 23:19 [PATCH v3 00/10] KVM: VMX: Fix APICv activation bugs Sean Christopherson
2025-12-05 23:19 ` [PATCH v3 01/10] KVM: VMX: Update SVI during runtime APICv activation Sean Christopherson
2025-12-05 23:19 ` [PATCH v3 02/10] KVM: nVMX: Immediately refresh APICv controls as needed on nested VM-Exit Sean Christopherson
2025-12-05 23:19 ` [PATCH v3 03/10] KVM: selftests: Add a test to verify APICv updates (while L2 is active) Sean Christopherson
2025-12-12  3:24   ` Chao Gao
2025-12-12 18:01     ` Sean Christopherson
2025-12-05 23:19 ` [PATCH v3 04/10] KVM: nVMX: Switch to vmcs01 to update PML controls on-demand if L2 is active Sean Christopherson
2025-12-24  7:53   ` Chao Gao
2025-12-05 23:19 ` [PATCH v3 05/10] KVM: nVMX: Switch to vmcs01 to update TPR threshold " Sean Christopherson
2025-12-25  6:38   ` Chao Gao
2025-12-05 23:19 ` [PATCH v3 06/10] KVM: nVMX: Switch to vmcs01 to update SVI " Sean Christopherson
2025-12-25  8:30   ` Chao Gao
2025-12-30 21:03     ` Sean Christopherson
2025-12-31  2:17       ` Chao Gao [this message]
2025-12-05 23:19 ` [PATCH v3 07/10] KVM: nVMX: Switch to vmcs01 to refresh APICv controls " Sean Christopherson
2025-12-26  1:45   ` Chao Gao
2025-12-05 23:19 ` [PATCH v3 08/10] KVM: nVMX: Switch to vmcs01 to update APIC page " Sean Christopherson
2025-12-26  2:01   ` Chao Gao
2025-12-05 23:19 ` [PATCH v3 09/10] KVM: nVMX: Switch to vmcs01 to set virtual APICv mode " Sean Christopherson
2025-12-26  5:16   ` Chao Gao
2025-12-05 23:19 ` [PATCH v3 10/10] KVM: x86: Update APICv ISR (a.k.a. SVI) as part of kvm_apic_update_apicv() Sean Christopherson
2025-12-26  5:16   ` Chao Gao
2025-12-10  0:25 ` [PATCH v3 00/10] KVM: VMX: Fix APICv activation bugs Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aVSH0GhLKqPcwPA5@intel.com \
    --to=chao.gao@intel.com \
    --cc=dongli.zhang@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox