[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration |
Date: |
Sat, 11 Oct 2014 13:58:54 +0100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Fri, Oct 10, 2014 at 09:33:04AM +0200, Marcin Gibuła wrote:
> >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.
>
> My guess is, it's not wrong, it's just outdated when second call occures.
> Maybe it's an ordering issue - could kvmclock state change handler be called
> before other activity is suspended (?)
Changing the ordering could just hide the problem. If the APIC state in
the kernel can change outside ioctl(KVM_RUN) calls, then it can't be
cached the same way the other registers loaded by
kvm_arch_get_registers() are. The current code invalidates the QEMU
register data (i.e. sets kvm_vcpu_dirty=false) only on 3 cases: 1) VCPU
init; 2) VCPU reset; 3) on kvm_cpu_exec(), immediately before calling
ioctl(KVM_RUN).
We may need a separate API to load APIC state? I don't know what are the
actual users X86CPU.apic_state, today.
--
Eduardo