From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34965) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFrry-0004EU-Ak for qemu-devel@nongnu.org; Fri, 08 Aug 2014 17:38:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XFrrs-0008Lt-5L for qemu-devel@nongnu.org; Fri, 08 Aug 2014 17:38:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFrrr-0008Kx-UL for qemu-devel@nongnu.org; Fri, 08 Aug 2014 17:38:32 -0400 Date: Fri, 8 Aug 2014 18:37:30 -0300 From: Marcelo Tosatti Message-ID: <20140808213730.GA13545@amt.cnet> References: <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> <53DFB511.70700@beyond.pl> <53DFD158.3070203@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <53DFD158.3070203@redhat.com> 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 Cc: Amit Shah , Fam Zheng , Andrey Korolyov , Marcin =?utf-8?Q?Gibu=C5=82a?= , "qemu-devel@nongnu.org" On Mon, Aug 04, 2014 at 08:30:48PM +0200, Paolo Bonzini wrote: > Il 04/08/2014 18:30, Marcin Gibu=C5=82a ha scritto: > >=20 > >=20 > > is this analysis deep enough for you? I don't know if that can be fix= ed > > with existing api as cpu_synchronize_all_states() is all or nothing k= ind > > of stuff. > >=20 > > 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/pu= t. > >=20 > > 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. >=20 > Yeah, I need to sit down and look at the code more closely... Perhaps = a > cpu_mark_all_dirty() is enough. Hi Paolo, cpu_clean_all_dirty, you mean? Has the same effect. Marcin's patch to add cpu_synchronize_state_always() has the same effect. What do you prefer ?