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;
>
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.