From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrTV1-00034e-6C for qemu-devel@nongnu.org; Sun, 29 Jan 2012 07:04:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrTUz-0007O6-R0 for qemu-devel@nongnu.org; Sun, 29 Jan 2012 07:04:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrTUz-0007Nc-JW for qemu-devel@nongnu.org; Sun, 29 Jan 2012 07:04:45 -0500 Message-ID: <4F2535D7.2090600@redhat.com> Date: Sun, 29 Jan 2012 14:04:39 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4F216E19.3040905@redhat.com> <4F217056.1030609@siemens.com> <4F21720A.9040306@siemens.com> <4F2173B7.2040904@redhat.com> <4F217537.8030202@siemens.com> <4F217612.4020707@redhat.com> <4F231874.1080503@web.de> <4F252090.7080103@redhat.com> <4F252981.7000708@redhat.com> <4F252A3D.8000905@web.de> <4F252B06.2070800@redhat.com> <4F253380.3040203@web.de> <4F253503.4050902@redhat.com> <4F253554.7080902@web.de> In-Reply-To: <4F253554.7080902@web.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Merging kvm-apic into qemu-kvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , KVM list On 01/29/2012 02:02 PM, Jan Kiszka wrote: > On 2012-01-29 13:01, Avi Kivity wrote: > > On 01/29/2012 01:54 PM, Jan Kiszka wrote: > >> On 2012-01-29 12:18, Avi Kivity wrote: > >>>>> > >>>>> 2. Migration is broken. > >>>> > >>>> OK, that's new. A trivial scenario? > >>>> > >>> > >>> Incoming command line: > >>> > >>> qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio > >>> -incoming tcp::4444 > >>> > >>> I expect you can remove '-smp 2' and it would still fail. > >>> > >> > >> Could you check if merge point 5fc4ecdf10 works for you? For me it does, > >> and b1b774ba43 starts failing. Given that the screen is corrupted on the > >> target side, I suspect the cirrus hwlib moving may have an influence. > >> > > > > It does, and I see the screen corruption as well (on the HEAD of the > > merge, not 5fc4). > > Looks like 59abb06198 (memory: fix dirty mask function length handling) > is causing this. Might be visible with upstream as well then. Any idea? > Blue posted patches for this. s/<=/