[Devel] [PATCH hci-8.1 v2 0/2] KVM: VMX: fix stale SVI after APICv is re-activated at runtime

[Devel] [PATCH hci-8.1 v2 0/2] KVM: VMX: fix stale SVI after APICv is re-activated at runtime

[Konstantin Khorenko]

A Windows guest with Hyper-V SynIC enlightenments runs with APICv
inhibited for as long as Windows uses SynIC auto-EOI. A system_reset
clears SynIC, the inhibit lifts and KVM re-activates APICv on every
vCPU. __kvm_vcpu_update_apicv() refreshes the VMCS exec controls but
never re-syncs GUEST_INTR_STATUS.SVI from the software vISR, so each
vCPU carries whatever SVI it had when APICv was last switched off.

With virtual-interrupt delivery the CPU derives the virtual PPR from
SVI. A stale SVI in class 0x2x blocks every vector of that class,
including the OVMF local APIC timer. The firmware halts waiting for a
timer tick that KVM considers deliverable, KVM re-enters the vCPU on
every HLT exit, and the guest never leaves BDS. Nothing in the software
state looks wrong: apicv_active is set, no inhibits, vIRR has the timer
vector, vISR is empty. Only the VMCS SVI disagrees. Rewriting the LAPIC
state of the stuck vCPU with its own contents re-synced SVI and the
guest booted into Windows, which confirms the mechanism on the live
reproducer. Full analysis is in the ticket.

Patch 1 is the upstream fix: re-sync SVI from vISR when APICv is
activated at runtime. Upstream took it in v6.19-rc2.

Patch 2 comes from the same upstream series. While reviewing the SVI
fix, Chao Gao found that an APICv (un)inhibit that lands while L2 is
active is lost: the nested VM-Exit pends KVM_REQ_APICV_UPDATE, but the
handler sees apicv_active already up to date and never refreshes
vmcs01. Sean Christopherson merged the two fixes together as the pair
meant for stable and marked patch 2 with Fixes and Cc: stable. It is
not the scenario reproduced here, but it is the same activation path,
and every stable branch that carries patch 1 carries patch 2 as well.

Both patches are taken as is: the diffs are identical to mainline, to
linux-6.12.y and to CentOS Stream 10, which already has both under
RHEL-151869. The prerequisites (kvm_apic_update_hwapic_isr() and the
vCPU-taking vmx_hwapic_isr_update() with the L2 deferral) are already
in our tree from the RHEL 10 kernel-6.12.0-211.16.1 import, so both
cherry-picks apply cleanly. Upstream has no Fixes against either
commit. The v7.0 rework that switches to vmcs01 on demand instead of
deferring the updates is a cleanup on top, explicitly not meant for
stable, and is not taken.

The failure has been seen three times across release lines and is tied
to a save/restore followed by a reset, so it is rare. Per the ticket
discussion this goes to hci-8.1, not 8.0 right before the release.

https://virtuozzo.atlassian.net/browse/VSTOR-147087

Changes in v2:
- Add the second fix from the same upstream series, "KVM: nVMX:
  Immediately refresh APICv controls as needed on nested VM-Exit"
  (mainline 2976313883091, taken via CentOS Stream 10 e299e09009929).
  Upstream ships the two together, and the second closes the case
  where the first one is not reached because the APICv update itself
  is lost while L2 is active.
- Add the cover letter.

Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
Dongli Zhang (1):
      ms/KVM: VMX: Update SVI during runtime APICv activation

Maxim Levitsky (1):
      ms/KVM: nVMX: Immediately refresh APICv controls as needed on nested VM-Exit

 arch/x86/kvm/vmx/nested.c | 3 ++-
 arch/x86/kvm/vmx/vmx.c    | 9 ---------
 arch/x86/kvm/x86.c        | 7 +++++++
 3 files changed, 9 insertions(+), 10 deletions(-)
---
base-commit: bd96ec5e17337493fefd459682cc21871238ef9c
change-id: 20260924-b4-prep-kvm-1f78405a4e7a

Best regards,
--  
Konstantin Khorenko <khorenko@virtuozzo.com>

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

[Devel] [PATCH hci-8.1 v2 1/2] ms/KVM: VMX: Update SVI during runtime APICv activation

[Konstantin Khorenko]

From: Dongli Zhang <dongli.zhang@oracle.com>

The APICv (apic->apicv_active) can be activated or deactivated at runtime,
for instance, because of APICv inhibit reasons. Intel VMX employs different
mechanisms to virtualize LAPIC based on whether APICv is active.

When APICv is activated at runtime, GUEST_INTR_STATUS is used to configure
and report the current pending IRR and ISR states. Unless a specific vector
is explicitly included in EOI_EXIT_BITMAP, its EOI will not be trapped to
KVM. Intel VMX automatically clears the corresponding ISR bit based on the
GUEST_INTR_STATUS.SVI field.

When APICv is deactivated at runtime, the VM_ENTRY_INTR_INFO_FIELD is used
to specify the next interrupt vector to invoke upon VM-entry. The
VMX IDT_VECTORING_INFO_FIELD is used to report un-invoked vectors on
VM-exit. EOIs are always trapped to KVM, so the software can manually clear
pending ISR bits.

There are scenarios where, with APICv activated at runtime, a guest-issued
EOI may not be able to clear the pending ISR bit.

Taking vector 236 as an example, here is one scenario.

1. Suppose APICv is inactive. Vector 236 is pending in the IRR.
2. To handle KVM_REQ_EVENT, KVM moves vector 236 from the IRR to the ISR,
and configures the VM_ENTRY_INTR_INFO_FIELD via vmx_inject_irq().
3. After VM-entry, vector 236 is invoked through the guest IDT. At this
point, the data in VM_ENTRY_INTR_INFO_FIELD is no longer valid. The guest
interrupt handler for vector 236 is invoked.
4. Suppose a VM exit occurs very early in the guest interrupt handler,
before the EOI is issued.
5. Nothing is reported through the IDT_VECTORING_INFO_FIELD because
vector 236 has already been invoked in the guest.
6. Now, suppose APICv is activated. Before the next VM-entry, KVM calls
kvm_vcpu_update_apicv() to activate APICv.
7. Unfortunately, GUEST_INTR_STATUS.SVI is not configured, although
vector 236 is still pending in the ISR.
8. After VM-entry, the guest finally issues the EOI for vector 236.
However, because SVI is not configured, vector 236 is not cleared.
9. ISR is stalled forever on vector 236.

Here is another scenario.

1. Suppose APICv is inactive. Vector 236 is pending in the IRR.
2. To handle KVM_REQ_EVENT, KVM moves vector 236 from the IRR to the ISR,
and configures the VM_ENTRY_INTR_INFO_FIELD via vmx_inject_irq().
3. VM-exit occurs immediately after the next VM-entry. The vector 236 is
not invoked through the guest IDT. Instead, it is saved to the
IDT_VECTORING_INFO_FIELD during the VM-exit.
4. KVM calls kvm_queue_interrupt() to re-queue the un-invoked vector 236
into vcpu->arch.interrupt. A KVM_REQ_EVENT is requested.
5. Now, suppose APICv is activated. Before the next VM-entry, KVM calls
kvm_vcpu_update_apicv() to activate APICv.
6. Although APICv is now active, KVM still uses the legacy
VM_ENTRY_INTR_INFO_FIELD to re-inject vector 236. GUEST_INTR_STATUS.SVI is
not configured.
7. After the next VM-entry, vector 236 is invoked through the guest IDT.
Finally, an EOI occurs. However, due to the lack of GUEST_INTR_STATUS.SVI
configuration, vector 236 is not cleared from the ISR.
8. ISR is stalled forever on vector 236.

Using QEMU as an example, vector 236 is stuck in ISR forever.

(qemu) info lapic 1
dumping local APIC state for CPU 1

LVT0	 0x00010700 active-hi edge  masked                      ExtINT (vec 0)
LVT1	 0x00010400 active-hi edge  masked                      NMI
LVTPC	 0x00000400 active-hi edge                              NMI
LVTERR	 0x000000fe active-hi edge                              Fixed  (vec 254)
LVTTHMR	 0x00010000 active-hi edge  masked                      Fixed  (vec 0)
LVTT	 0x000400ec active-hi edge                 tsc-deadline Fixed  (vec 236)
Timer	 DCR=0x0 (divide by 2) initial_count = 0 current_count = 0
SPIV	 0x000001ff APIC enabled, focus=off, spurious vec 255
ICR	 0x000000fd physical edge de-assert no-shorthand
ICR2	 0x00000000 cpu 0 (X2APIC ID)
ESR	 0x00000000
ISR	 236
IRR	 37(level) 236

The issue isn't applicable to AMD SVM as KVM simply writes vmcb01 directly
irrespective of whether L1 (vmcs01) or L2 (vmcb02) is active (unlike VMX,
there is no need/cost to switch between VMCBs).  In addition,
APICV_INHIBIT_REASON_IRQWIN ensures AMD SVM AVIC is not activated until
the last interrupt is EOI'd.

Fix the bug by configuring Intel VMX GUEST_INTR_STATUS.SVI if APICv is
activated at runtime.

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
Link: https://patch.msgid.link/20251110063212.34902-1-dongli.zhang@oracle.com
[sean: call out that SVM writes vmcb01 directly, tweak comment]
Link: https://patch.msgid.link/20251205231913.441872-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
(cherry picked from commit b2849bec936be642b5420801f902337f2507648e)

https://virtuozzo.atlassian.net/browse/VSTOR-147087

Feature: fix ms/kvm
Signed-off-by: Denis V. Lunev <den@openvz.org>
---
 arch/x86/kvm/vmx/vmx.c | 9 ---------
 arch/x86/kvm/x86.c     | 7 +++++++
 2 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index ddf8ee3f905b3..00ec973140374 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6768,15 +6768,6 @@ void vmx_hwapic_isr_update(struct kvm_vcpu *vcpu, int max_isr)
 	 * VM-Exit, otherwise L1 with run with a stale SVI.
 	 */
 	if (is_guest_mode(vcpu)) {
-		/*
-		 * KVM is supposed to forward intercepted L2 EOIs to L1 if VID
-		 * is enabled in vmcs12; as above, the EOIs affect L2's vAPIC.
-		 * Note, userspace can stuff state while L2 is active; assert
-		 * that VID is disabled if and only if the vCPU is in KVM_RUN
-		 * to avoid false positives if userspace is setting APIC state.
-		 */
-		WARN_ON_ONCE(vcpu->wants_to_run &&
-			     nested_cpu_has_vid(get_vmcs12(vcpu)));
 		to_vmx(vcpu)->nested.update_vmcs01_hwapic_isr = true;
 		return;
 	}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index dd1769ba8da4e..f7e4350b33403 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -10566,9 +10566,16 @@ void __kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu)
 	 * pending. At the same time, KVM_REQ_EVENT may not be set as APICv was
 	 * still active when the interrupt got accepted. Make sure
 	 * kvm_check_and_inject_events() is called to check for that.
+	 *
+	 * Update SVI when APICv gets enabled, otherwise SVI won't reflect the
+	 * highest bit in vISR and the next accelerated EOI in the guest won't
+	 * be virtualized correctly (the CPU uses SVI to determine which vISR
+	 * vector to clear).
 	 */
 	if (!apic->apicv_active)
 		kvm_make_request(KVM_REQ_EVENT, vcpu);
+	else
+		kvm_apic_update_hwapic_isr(vcpu);
 
 out:
 	preempt_enable();

-- 
2.43.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

[Devel] [PATCH hci-8.1 v2 2/2] ms/KVM: nVMX: Immediately refresh APICv controls as needed on nested VM-Exit

[Konstantin Khorenko]

From: Maxim Levitsky <mlevitsk@redhat.com>

JIRA: https://issues.redhat.com/browse/RHEL-151869

commit 29763138830916f46daaa50e83e7f4f907a3236b
Author: Dongli Zhang <dongli.zhang@oracle.com>
Date:   Fri Dec 5 15:19:05 2025 -0800

    KVM: nVMX: Immediately refresh APICv controls as needed on nested VM-Exit

    If an APICv status updated was pended while L2 was active, immediately
    refresh vmcs01's controls instead of pending KVM_REQ_APICV_UPDATE as
    kvm_vcpu_update_apicv() only calls into vendor code if a change is
    necessary.

    E.g. if APICv is inhibited, and then activated while L2 is running:

      kvm_vcpu_update_apicv()
      |
      -> __kvm_vcpu_update_apicv()
         |
         -> apic->apicv_active = true
          |
          -> vmx_refresh_apicv_exec_ctrl()
             |
             -> vmx->nested.update_vmcs01_apicv_status = true
              |
              -> return

    Then L2 exits to L1:

      __nested_vmx_vmexit()
      |
      -> kvm_make_request(KVM_REQ_APICV_UPDATE)

      vcpu_enter_guest(): KVM_REQ_APICV_UPDATE
      -> kvm_vcpu_update_apicv()
         |
         -> __kvm_vcpu_update_apicv()
            |
            -> return // because if (apic->apicv_active == activate)

    Reported-by: Chao Gao <chao.gao@intel.com>
    Closes: https://lore.kernel.org/all/aQ2jmnN8wUYVEawF@intel.com
    Fixes: 7c69661e225c ("KVM: nVMX: Defer APICv updates while L2 is active until L1 is active")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
    [sean: write changelog]
    Link: https://patch.msgid.link/20251205231913.441872-3-seanjc@google.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>

(cherry picked from commit e299e09009929a5b4a5f209617ab25bcd08e41bb)

https://virtuozzo.atlassian.net/browse/VSTOR-147087
Feature: fix ms/kvm

Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
 arch/x86/kvm/vmx/nested.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 7ff9a8d2c2c93..8c771d8c35e35 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -18,6 +18,7 @@
 #include "trace.h"
 #include "vmx.h"
 #include "smm.h"
+#include "x86_ops.h"
 
 static bool __read_mostly enable_shadow_vmcs = 1;
 module_param_named(enable_shadow_vmcs, enable_shadow_vmcs, bool, S_IRUGO);
@@ -5087,7 +5088,7 @@ void __nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 vm_exit_reason,
 
 	if (vmx->nested.update_vmcs01_apicv_status) {
 		vmx->nested.update_vmcs01_apicv_status = false;
-		kvm_make_request(KVM_REQ_APICV_UPDATE, vcpu);
+		vmx_refresh_apicv_exec_ctrl(vcpu);
 	}
 
 	if (vmx->nested.update_vmcs01_hwapic_isr) {

-- 
2.43.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

Re: [Devel] [PATCH hci-8.1 v2 0/2] KVM: VMX: fix stale SVI after APICv is re-activated at runtime

[Konstantin Khorenko]

On Thu, 24 Sep 2026 19:15:36 +0200, Konstantin Khorenko wrote:
> KVM: VMX: fix stale SVI after APICv is re-activated at runtime
> 
> A Windows guest with Hyper-V SynIC enlightenments runs with APICv
> inhibited for as long as Windows uses SynIC auto-EOI. A system_reset
> clears SynIC, the inhibit lifts and KVM re-activates APICv on every
> vCPU. __kvm_vcpu_update_apicv() refreshes the VMCS exec controls but
> never re-syncs GUEST_INTR_STATUS.SVI from the software vISR, so each
> vCPU carries whatever SVI it had when APICv was last switched off.
> 
> [...]

Applied to branch-rh10-6.12.0-211.52.1.22.x.vz10-ovz, will be released in rh10-6.12.0-211.52.1.22.3.vz10, thanks!

[1/2] ms/KVM: VMX: Update SVI during runtime APICv activation
      https://bitbucket.org/virtuozzocore/vzkernel.vzs/commits/0571a0e123ea
[2/2] ms/KVM: nVMX: Immediately refresh APICv controls as needed on nested VM-Exit
      https://bitbucket.org/virtuozzocore/vzkernel.vzs/commits/510fb493f8a3

-- 
Konstantin Khorenko <khorenko@virtuozzo.com>

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel