Re: [patch 2/2] KVM: fix kvm_vcpu_kick vs __vcpu_run race

Avi Kivity
2008-04-11T12:18:19Z

Marcelo Tosatti wrote:
> There is a window open between testing of pending IRQ's
> and assignment of guest_mode in __vcpu_run.
>
> Injection of IRQ's can race with __vcpu_run as follows:
>
> CPU0 CPU1
> kvm_x86_ops->run()
> vcpu->guest_mode = 0 SET_IRQ_LINE ioctl
> ..
> kvm_x86_ops->inject_pending_irq
> kvm_cpu_has_interrupt()
>
> apic_test_and_set_irr()
> kvm_vcpu_kick
> if (vcpu->guest_mode)
> send_ipi()
>
> vcpu->guest_mode = 1
>
> So move guest_mode=1 assignment before ->inject_pending_irq, and make
> sure that it won't reorder after it.
>
> @@ -3944,11 +3950,12 @@ static void vcpu_kick_intr(void *info)
> void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
> {
> int ipi_pcpu = vcpu->cpu;
> + int cpu = smp_processor_id();
>
> if (waitqueue_active(&vcpu->wq)) {
> wake_up_interruptible(&vcpu->wq);
> ++vcpu->stat.halt_wakeup;
> }
> - if (vcpu->guest_mode)
> + if (vcpu->guest_mode && vcpu->cpu != cpu)
> smp_call_function_single(ipi_pcpu, vcpu_kick_intr, vcpu, 0, 0);
> }
>
>

kvm_vcpu_kick() can be called from nonatomic contexts, so the vcpu->cpu
== cpu check is dangerous (and will warn on preemptible kernels, no?)

--
Any sufficiently difficult bug is indistinguishable from a feature.