From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1guq-0000MP-Eq for qemu-devel@nongnu.org; Thu, 18 Dec 2014 14:39:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1guk-0002Oc-94 for qemu-devel@nongnu.org; Thu, 18 Dec 2014 14:39:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1guk-0002O9-1s for qemu-devel@nongnu.org; Thu, 18 Dec 2014 14:39:10 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBIJd8jK027135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 18 Dec 2014 14:39:09 -0500 Date: Thu, 18 Dec 2014 19:39:04 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20141218193904.GM4744@work-vm> References: <1418148909-19870-1-git-send-email-dgilbert@redhat.com> <1418148909-19870-3-git-send-email-dgilbert@redhat.com> <5488C375.4090601@redhat.com> <20141211194503.GL2567@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141211194503.GL2567@work-vm> 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: Paolo Bonzini Cc: jsnow@redhat.com, qemu-devel@nongnu.org * Dr. David Alan Gilbert (dgilbert@redhat.com) wrote: > * Paolo Bonzini (pbonzini@redhat.com) wrote: > > > > > > On 09/12/2014 19:15, Dr. David Alan Gilbert (git) wrote: > > > (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. > > > > > Also, what is the ATAPI command that is being run? > > The command in my test case is: > 28 00 00 06 df b8 00 00 40 00 00 00 > so just a standard READ (10); I guess it's possible that other OSs/operations > maybe doing different READ variants. > > > What is the part of the state that is not being migrated? > > I can't see lba, io_buffer_index, io_buffer_size or cd_sector_size being passed > to a VMSTATE_ macro; and having noticed that those are missing I didn't dig much > deeper. > (I'll admit to not really understanding the interaction between the core.c, atapi.c > and pci.c dma code properly to know if it can be reconstructed). Actually, another argument for this is that even if we come along and add the extra state as a subsection, we can still do this as a fallback when receiving older streams. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK