|
From: | Marcin Gibuła |
Subject: | Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration |
Date: | Fri, 18 Jul 2014 11:48:41 +0200 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
W dniu 2014-07-18 11:37, Paolo Bonzini pisze:
Il 18/07/2014 11:32, Marcin Gibuła ha scritto: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; }But, I don't set cpu->kvm_vcpu_dirty anywhere (?).Yeah, the next CPU entry will *not* call kvm_arch_put_registers with your change. It will call it with vanilla cpu_synchronize_all_states().
That's because in kvmclock, it's used only to read cpu registers, not edit them.
Now, because making this call "invisible" makes it work, I'm speculating that following happens:
[migration starts] kvmclock: calls cpu_synchronize_all_states() somewhere in qemu: completes IO somewhere in qemu: calls cpu_synchronize_all_states() <- old stateIs it (or something similar) possible? I didn't dig deep enough into internals yet, but perhaps you could point if thats the right direction?
-- mg
[Prev in Thread] | Current Thread | [Next in Thread] |