From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1kil-0004qX-5E for qemu-devel@nongnu.org; Thu, 18 Dec 2014 18:43:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1kie-00054K-RD for qemu-devel@nongnu.org; Thu, 18 Dec 2014 18:43:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1kie-00053n-Gj for qemu-devel@nongnu.org; Thu, 18 Dec 2014 18:42:56 -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 sBINgteG004132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 18 Dec 2014 18:42:55 -0500 Message-ID: <5493667D.60107@redhat.com> Date: Thu, 18 Dec 2014 18:42:53 -0500 From: John Snow MIME-Version: 1.0 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> <20141218193904.GM4744@work-vm> In-Reply-To: <20141218193904.GM4744@work-vm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: "Dr. David Alan Gilbert" , Paolo Bonzini Cc: qemu-devel@nongnu.org On 12/18/2014 02:39 PM, Dr. David Alan Gilbert wrote: > * 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. > Fair enough. I vote we give this hack a shot for now, then. I can always put this in my basket of things to look at ($later) after I have finished ($other_things).