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

[Konstantin Khorenko <khorenko@virtuozzo.com>]

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