From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58431) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEL9k-0005VI-Hs for qemu-devel@nongnu.org; Mon, 04 Aug 2014 12:30:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XEL9c-0000XF-QZ for qemu-devel@nongnu.org; Mon, 04 Aug 2014 12:30:40 -0400 Received: from mx.beyond.pl ([92.43.117.49]:57799) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEL9c-0000X7-EQ for qemu-devel@nongnu.org; Mon, 04 Aug 2014 12:30:32 -0400 Message-ID: <53DFB511.70700@beyond.pl> Date: Mon, 04 Aug 2014 18:30:09 +0200 From: =?UTF-8?B?TWFyY2luIEdpYnXFgmE=?= MIME-Version: 1.0 References: <20140715210948.GA20036@amt.cnet> <53C5A4C9.80609@redhat.com> <20140716011634.GA30717@amt.cnet> <20140716115229.GA7741@amt.cnet> <53C6EE7C.60702@beyond.pl> <53C79C41.4000800@beyond.pl> <53C7B989.9000203@beyond.pl> <53C7CEE5.4080006@beyond.pl> <53C8DF68.5040705@redhat.com> <53D7D2B5.8060500@redhat.com> <53D8DEE1.8080905@beyond.pl> <53D8F546.4010803@redhat.com> <53D96DBE.2040700@beyond.pl> <53DA283F.4030709@beyond.pl> In-Reply-To: <53DA283F.4030709@beyond.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Andrey Korolyov Cc: Amit Shah , Marcelo Tosatti , Fam Zheng , "qemu-devel@nongnu.org" W dniu 2014-07-31 13:27, Marcin Gibu=C5=82a 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=20 with existing api as cpu_synchronize_all_states() is all or nothing kind=20 of stuff. Kvmclock needs it only to read current cpu registers, so syncing=20 everything is not really necessary. Perhaps exporting one of=20 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=20 cpu_synchronize_all_states() in its change state callback it could=20 result in same error so perhaps more generic approach is needed. --=20 mg