KVM: test for LAPIC timer migration request after disabling IRQ's

Quoted 16 lines · Avi Kivity

Quoted 14 lines · Marcelo Tosatti

(resending to [email protected])

A guest vcpu instance can be scheduled to a different physical CPU between the test for KVM_REQ_MIGRATE_TIMER and local_irq_disable().

If that happens, the timer will only be migrated to the current pCPU on the next exit, meaning that guest LAPIC timer event can be delayed until a host timer interrupt is triggered.

Fix that by testing the migration request after local_irq_disable(), similarly to what is done for KVM_REQ_MMU_RELOAD.

Quoted 2 lines

An alternative fix is to have __apic_timer_fn() call smp_call_function_single() to the current vcpu->cpu with a dummy function (not saying it's better).

smp_call_function_single() can't function from IRQ context (there is a global lock protecting internal data and waiting for a remote CPU to finish a function from IRQ context does not sound good). Remember the vcpu_kick() in the pit timer handler? :)

Quoted 10 lines

How about

   if (vcpu->requests) {
         local_irq_enable();
         preempt_enable();
         r = 1;
         goto out;
   }

Quoted 4 lines

?

It ensures that we never enter guest mode with _any_ pending request, so long as request bits are set on vcpu->cpu or are followed by an IPI. I think it fixes a similar race with KVM_REQ_TLB_FLUSH.

Yes doing it for any pending requests sounds much better.

As for KVM_REQ_TLB_FLUSH, the check happens after local_irq_disable() already. Which is sort of problematic in that requests arriving after entering the IRQ-disabled section but before the test_and_clear_bit() will run ->tlb_flush but won't clear the pending IPI, so there's an exit for nothing. Probably uncommon though.