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

[Eduardo Habkost <ehabkost@redhat.com>]

On Mon, Aug 04, 2014 at 06:30:09PM +0200, Marcin Gibuła wrote:
> W dniu 2014-07-31 13:27, Marcin Gibuła pisze:
> >>>Can you dump *env before and after the call to kvm_arch_get_registers?
> >>
> >>Yes, but it seems they are equal - I used memcmp() to compare them. Is
> >>there any other side effect that cpu_synchronize_all_states() may have?
> >
> >I think I found it.
> >
> >The reason for hang is, because when second call to
> >kvm_arch_get_registers() is skipped, it also skips kvm_get_apic() which
> >updates cpu->apic_state.
> 
> Paolo,
> 
> is this analysis deep enough for you? I don't know if that can be fixed with
> existing api as cpu_synchronize_all_states() is all or nothing kind of
> stuff.
> 
> Kvmclock needs it only to read current cpu registers, so syncing everything
> is not really necessary. Perhaps exporting one of kvm_arch_get_* would be
> enough. And it wouldn't mess with lazy get/put.
> 
> On the other hand, if in future any other driver adds
> cpu_synchronize_all_states() in its change state callback it could result in
> same error so perhaps more generic approach is needed.

Does anybody know why the APIC state loaded by the first call to
kvm_arch_get_registers() is wrong, in the first place? What exactly is
different in the APIC state in the second kvm_arch_get_registers() call,
and when/why does it change?

If cpu_synchronize_state() does the wrong thing if it is called at the
wrong moment, then we may have other hidden bugs, because the user can
trigger cpu_synchronize_all_states() calls arbitrarily using monitor
commands.

-- 
Eduardo