From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33888)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XEN2H-0006jf-T6
	for qemu-devel@nongnu.org; Mon, 04 Aug 2014 14:31:12 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XEN29-0003wI-Ld
	for qemu-devel@nongnu.org; Mon, 04 Aug 2014 14:31:05 -0400
Received: from mx1.redhat.com ([209.132.183.28]:46394)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XEN29-0003w6-CN
	for qemu-devel@nongnu.org; Mon, 04 Aug 2014 14:30:57 -0400
Message-ID: <53DFD158.3070203@redhat.com>
Date: Mon, 04 Aug 2014 20:30:48 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <CABYiri8_naTkFgVJEwy9O52gRYHTVGwo-6sH-r+0FOFPf0Zm8w@mail.gmail.com>	<CABYiri9Z3iDPn1JRSR-_x4SntBZms3yQPaChSbyRFAi2W9yScw@mail.gmail.com>	<53C5A4C9.80609@redhat.com>	<CABYiri9MigkURgV273kVjhnYxLz_WnQtsZzToy531vY0cjiGkQ@mail.gmail.com>	<20140716011634.GA30717@amt.cnet>	<CABYiri96UbyO238wYKz9OC5Tn69jZ7XdaoEX1A2ucbPTrbA1tg@mail.gmail.com>	<20140716115229.GA7741@amt.cnet>	<CABYiri9mNpaY35EVGLTjR6c7SkY2HgttpN_3NihFy2jcOQ9raQ@mail.gmail.com>	<CABYiri_vDLR=PATk1Lb99nDcJf4Q-yajayyMR1Tuv6bfwVUjgQ@mail.gmail.com>	<53C6EE7C.60702@beyond.pl>	<CABYiri8HdQhsoaf2=FHLG+KyrNj05FT015bNcEk9ngH	6Dxo7dQ@mail.gmail.com>	<53C79C41.4000800@beyond.pl>	<53C7B989.9000203@beyond.pl>	<CABYiri-aeP=0NcKaoaa=_au9sruvxnPVNri_Vy2KxKFHRj2fUw@mail.gmail.com>	<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>
In-Reply-To: <53DFB511.70700@beyond.pl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?UTF-8?B?TWFyY2luIEdpYnXFgmE=?= <m.gibula@beyond.pl>, Andrey Korolyov <andrey@xdel.ru>
Cc: Amit Shah <amit.shah@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, Fam Zheng <famz@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

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 fixed
> with existing api as cpu_synchronize_all_states() is all or nothing kin=
d
> 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/put.
>=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.

Yeah, I need to sit down and look at the code more closely...  Perhaps a
cpu_mark_all_dirty() is enough.

Paolo