From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xz9fo-0000Ru-Nr for qemu-devel@nongnu.org; Thu, 11 Dec 2014 14:45:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xz9fi-0007IE-1w for qemu-devel@nongnu.org; Thu, 11 Dec 2014 14:45:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xz9fh-0007H9-RH for qemu-devel@nongnu.org; Thu, 11 Dec 2014 14:45:09 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBBJj8MK031236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 11 Dec 2014 14:45:08 -0500 Date: Thu, 11 Dec 2014 19:45:04 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20141211194503.GL2567@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5488C375.4090601@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: Paolo Bonzini Cc: jsnow@redhat.com, qemu-devel@nongnu.org * 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). Dave > Paolo -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK