From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dS6h9-0006He-4z for qemu-devel@nongnu.org; Mon, 03 Jul 2017 15:07:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dS6h6-0002wH-30 for qemu-devel@nongnu.org; Mon, 03 Jul 2017 15:07:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34314) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dS6h5-0002vQ-SO for qemu-devel@nongnu.org; Mon, 03 Jul 2017 15:07:36 -0400 Date: Mon, 3 Jul 2017 20:07:28 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20170703190728.GE2206@work-vm> References: <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> <20170703192353-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170703192353-mutt-send-email-mst@kernel.org> Subject: Re: [Qemu-devel] postcopy migration hangs while loading virtio state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Christian Borntraeger , Juan Quintela , qemu-devel , thuth@redhat.com * Michael S. Tsirkin (mst@redhat.com) wrote: > 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? Hmm no, I don't really want to change the !s390 behaviour, especially since it causes allocation that we otherwise avoid and Andrea's reply tothe original post pointed out it's not necessary. Dave > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK