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

[xinguo]

For context, the first issue I hit was the one fixed by:

  87d0f901a9bd ("KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated")

After I backported that commit, the original failure no longer
reproduces.  I then started stress testing repeated AVIC
activate/deactivate transitions, and under that stress workload I hit
the new Windows crash that made me look at the dummy V_IRQ path.

So this may be a separate issue in the AVIC inhibit / IRQ-window area,
rather than the original CR8-intercept / TPR problem.  My current tree
has 87d0f901a9bd applied, but does not yet include the four IRQ-window
inhibit commits you pointed out.

I'll backport those commits as well and re-run the same AVIC toggle
stress test. 

> 2026年6月11日 08:04，Sean Christopherson <seanjc@xxxxxxxxxx> 写道：
> 
> 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.