Re: [PATCH] KVM: SVM: Clear dummy V_IRQ in vmcb01 when deactivating AVIC

[Sean Christopherson <seanjc@google.com>]

On Thu, Jun 11, 2026, xinguo wrote:
> Fair point, my changelog reasoning is incomplete and I owe you data
> rather than speculation.

Oh, I'm not doubting that there is a bug, I just don't think that purging V_IRQ
when AVIC is disabled is the right fix.

> What I actually trigger is a workload that repeatedly toggles AVIC
> on and off, i.e. avic_activate_vmcb() / avic_deactivate_vmcb() get
> called many times in quick succession.  Under that load the Windows
> guest blue screens with STATUS_INTEGER_DIVIDE_BY_ZERO.

What kernel version are you using?  And do you happen to know what exactly is
causing AVIC to be (un)inhibited?  I ask because these commits that are landing
in 7.1 might be relevant:

  fa78a514d632ed2428b7c573108d9658c00d536e KVM: Isolate apicv_update_lock and apicv_nr_irq_window_req in a cacheline
  5617dddcfa30129562d7028ec766797d8c345f36 KVM: SVM: Optimize IRQ window inhibit handling
  6563ddadd169cc6f509a75b3ff8354309dcb9080 KVM: SVM: Fix IRQ window inhibit handling across multiple vCPUs
  7b402ec851cb66e73ee35913c7d802bba820086b KVM: SVM: Fix clearing IRQ window inhibit with nested guests

> From the dump, Windows takes the bugcheck while dispatching an
> interrupt: an unhandled #DE is raised inside the interrupt dispatch
> path and ultimately reported by nt!KiInterruptHandler.  The faulting
> RIP saved in the trap frame is:
> 
> 	je   nt!KiInterruptSubDispatchNoLockNoEtw+0xd5
> 
> which is a conditional branch, not a div/idiv.  In other words, the
> guest is being vectored through IDT entry 0 (#DE) at an instruction
> boundary that has nothing to do with division, which is consistent
> with the CPU delivering vector 0 from KVM rather than the guest
> actually executing a faulting div.  That is what made me suspect a
> stale dummy V_IRQ (vector=0, V_IRQ=1) becoming effective once AVIC
> is disabled.
> 
> I agree this needs to be backed by traces, not just by that
> hypothesis.  Let me instrument svm_set_vintr(), svm_clear_vintr(),
> the intercept-recalc paths, and avic_deactivate_vmcb() to capture
> vmcb01's int_ctl / int_vector / INTERCEPT_VINTR / is_guest_mode()
> at each transition, reproduce the crash, and come back with the
> actual call sequence that leaves vmcb01 in a state where V_IRQ
> becomes effective once AVIC is disabled.
> 
> Please hold off on this patch in the meantime; I'll resend (or drop
> it) based on what the trace shows.