Re: [PATCH 1/1] KVM: VMX: configure SVI during runtime APICv activation

[Chao Gao <chao.gao@intel.com>]

On Mon, Nov 03, 2025 at 01:41:15PM -0800, Dongli Zhang wrote:
>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.

which APICv inhibitor is cleared in this step?

<snip>

>
>diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>index b4b5d2d09634..a20cca69f2ed 100644
>--- a/arch/x86/kvm/x86.c
>+++ b/arch/x86/kvm/x86.c
>@@ -10873,6 +10873,9 @@ void __kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu)
> 	kvm_apic_update_apicv(vcpu);
> 	kvm_x86_call(refresh_apicv_exec_ctrl)(vcpu);
> 
>+	if (apic->apicv_active && !is_guest_mode(vcpu))
>+		kvm_apic_update_hwapic_isr(vcpu);
>+

Why is the nested case exempted here? IIUC, kvm_apic_update_hwapic_isr()
guarantees an update to VMCS01's SVI even if the vCPU is in guest mode.

And there is already a check against apicv_active right below. So, to be
concise, how about:

	if (!apic->apicv_active)
		kvm_make_request(KVM_REQ_EVENT, vcpu);
	else
		kvm_apic_update_hwapic_isr(vcpu);

And the comment below can be extended to state that when APICv gets enabled,
updating SVI is necessary; otherwise, SVI won't reflect the highest bit in vISR
and the next EOI from the guest won't be virtualized correctly, as the CPU will
clear the SVI bit from vISR.

> 	/*
> 	 * When APICv gets disabled, we may still have injected interrupts
> 	 * pending. At the same time, KVM_REQ_EVENT may not be set as APICv was
>-- 
>2.39.3
>
>