qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration


From: Amit Shah
Subject: Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration
Date: Fri, 18 Jul 2014 14:27:54 +0530

On (Fri) 18 Jul 2014 [10:48:40], Paolo Bonzini wrote:
> Il 17/07/2014 15:25, Marcin Gibuła ha scritto:
> >+static void do_kvm_cpu_synchronize_state_always(void *arg)
> >+{
> >+    CPUState *cpu = arg;
> >+
> >+    kvm_arch_get_registers(cpu);
> >+}
> >+
> 
> The name of the hack^Wfunction is tricky, because compared to
> do_kvm_cpu_synchronize_state there are three things you change:
> 
> 1) you always synchronize the state
> 
> 2) the next call to do_kvm_cpu_synchronize_state will do
> kvm_arch_get_registers
> 
> 3) the next CPU entry will call kvm_arch_put_registers:
> 
>         if (cpu->kvm_vcpu_dirty) {
>             kvm_arch_put_registers(cpu, KVM_PUT_RUNTIME_STATE);
>             cpu->kvm_vcpu_dirty = false;
>         }
> 
> It is easy to find out if the "fix" is related to 1 or 2/3: just write
> 
>      if (cpu->kvm_vcpu_dirty) {
>          printf ("do_kvm_cpu_synchronize_state_always: look at 2/3\n");
>          kvm_arch_get_registers(cpu);
>      } else {
>          printf ("do_kvm_cpu_synchronize_state_always: look at 1\n");
>      }
> 
> To further refine between 2 and 3, I suppose you can set a breakpoint on
> cpu_synchronize_all_states and kvm_cpu_exec, and see which is called first
> after cpu_synchronize_all_states_always.
> 
> I still lean very much towards reverting the patches now.  We can reapply
> them, fixed, in 2.1.1.

FWIW I agree with this plan.

                Amit



reply via email to

[Prev in Thread] Current Thread [Next in Thread]