From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49286) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dS49x-0003rm-Ef for qemu-devel@nongnu.org; Mon, 03 Jul 2017 12:25:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dS49u-0001KL-9F for qemu-devel@nongnu.org; Mon, 03 Jul 2017 12:25:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60358) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dS49u-0001JM-3E for qemu-devel@nongnu.org; Mon, 03 Jul 2017 12:25:10 -0400 Date: Mon, 3 Jul 2017 19:25:07 +0300 From: "Michael S. Tsirkin" Message-ID: <20170703192353-mutt-send-email-mst@kernel.org> References: <20170424105344.GF2362@work-vm> <75a4c5ff-385e-31ac-5f86-883b082cd94e@de.ibm.com> <20170424143516.GD2075@work-vm> <5c0608dd-ba22-dc09-71a1-bb95c977f77d@de.ibm.com> <20170424191202.GQ2362@work-vm> <097a5085-1128-cf2d-abc4-54660a608f36@de.ibm.com> <20170426110144.GF2098@work-vm> <20170630163139.GC2437@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170630163139.GC2437@work-vm> Subject: Re: [Qemu-devel] postcopy migration hangs while loading virtio state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Christian Borntraeger , Juan Quintela , qemu-devel , thuth@redhat.com On Fri, Jun 30, 2017 at 05:31:39PM +0100, Dr. David Alan Gilbert wrote: > * Christian Borntraeger (borntraeger@de.ibm.com) wrote: > > On 04/26/2017 01:45 PM, Christian Borntraeger wrote: > > > > >> Hmm, I have a theory, if the flags field has bit 1 set, i.e. RAM_SAVE_FLAG_COMPRESS > > >> then try changing ram_handle_compressed to always do the memset. > > > > > > FWIW, changing ram_handle_compressed to always memset makes the problem go away. > > > > It is still running fine now with the "always memset change" > > Did we ever nail down a fix for this; as I remember Andrea said > we shouldn't need to do that memset, but we came to the conclusion > it was something specific to how s390 protection keys worked. > > Dave No we didn't. Let's merge that for now, with a comment that we don't really understand what's going on? > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK