From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIFrB-0006kR-S4 for qemu-devel@nongnu.org; Mon, 02 Feb 2015 07:12:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIFr6-00062r-SD for qemu-devel@nongnu.org; Mon, 02 Feb 2015 07:11:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48363) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIFr6-00062g-LB for qemu-devel@nongnu.org; Mon, 02 Feb 2015 07:11:52 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t12CBpvJ017652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 2 Feb 2015 07:11:52 -0500 Date: Mon, 2 Feb 2015 13:11:48 +0100 From: Kevin Wolf Message-ID: <20150202121148.GB9478@noname.redhat.com> References: <1418148909-19870-1-git-send-email-dgilbert@redhat.com> <1418148909-19870-3-git-send-email-dgilbert@redhat.com> <54B94A36.5060409@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B94A36.5060409@redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/2] atapi migration: Throw recoverable error to avoid recovery List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: pbonzini@redhat.com, "Dr. David Alan Gilbert (git)" , qemu-devel@nongnu.org Am 16.01.2015 um 18:28 hat John Snow geschrieben: > > > On 12/09/2014 01:15 PM, Dr. David Alan Gilbert (git) wrote: > >From: "Dr. David Alan Gilbert" > > > >(With the previous atapi_dma flag recovery) > >If migration happens between the ATAPI command being written and the > >bmdma being started, the DMA is dropped. Eventually the guest times > >out and recovers, but that can take many seconds. > >(This is rare, on a pingpong reading the CD continuously I hit > >this about ~1/30-1/50 migrates) > > > >I don't think we've got enough state to be able to recover safely > >at this point, so I throw a 'medium error, no seek complete' > >that I'm assuming guests will try and recover from an apparently > >dirty CD. > > > >OK, it's a hack, the real solution is probably to push a lot of > >ATAPI state into the migration stream, but this is a fix that > >works with no stream changes. Tested only on Linux (both RHEL5 > >(pre-libata) and RHEL7). > > > >Signed-off-by: Dr. David Alan Gilbert > I think this workaround is sensible until we develop a more precise fix. > > Reviewed-by: John Snow Thanks, applied all to the block branch. Kevin