From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41717)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <m.gibula@beyond.pl>) id 1XcUhT-0005Lq-VO
	for qemu-devel@nongnu.org; Fri, 10 Oct 2014 03:33:27 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <m.gibula@beyond.pl>) id 1XcUhM-0007py-GG
	for qemu-devel@nongnu.org; Fri, 10 Oct 2014 03:33:19 -0400
Received: from mx.beyond.pl ([92.43.117.49]:34754)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <m.gibula@beyond.pl>) id 1XcUhM-0007pN-AH
	for qemu-devel@nongnu.org; Fri, 10 Oct 2014 03:33:12 -0400
Message-ID: <54378BB0.5060509@beyond.pl>
Date: Fri, 10 Oct 2014 09:33:04 +0200
From: =?UTF-8?B?TWFyY2luIEdpYnXFgmE=?= <m.gibula@beyond.pl>
MIME-Version: 1.0
References: <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>
	<20141009190709.GC23667@thinpad.lan.raisama.net>
In-Reply-To: <20141009190709.GC23667@thinpad.lan.raisama.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Eduardo Habkost <ehabkost@redhat.com>
Cc: Andrey Korolyov <andrey@xdel.ru>, Fam Zheng <famz@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Amit Shah <amit.shah@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>

> 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 (?)

I didn't pursue it further, cause I don't know too much (anything 
really) about QEMU/APIC internals and how to track its changes.

-- 
mg