From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiMFl-0003YJ-9u for qemu-devel@nongnu.org; Fri, 31 May 2013 06:08:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UiMFk-00078J-1I for qemu-devel@nongnu.org; Fri, 31 May 2013 06:08:09 -0400 Message-ID: <1369994875.3928.137.camel@pasglop> From: Benjamin Herrenschmidt Date: Fri, 31 May 2013 20:07:55 +1000 In-Reply-To: <51A83C18.2030102@ozlabs.ru> References: <1367545092-19980-1-git-send-email-david@gibson.dropbear.id.au> <1367545092-19980-8-git-send-email-david@gibson.dropbear.id.au> <51875DA7.4090308@redhat.com> <51A301AC.8070101@ozlabs.ru> <51A30528.9020708@redhat.com> <51A83C18.2030102@ozlabs.ru> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 7/8] pseries: savevm support for PAPR virtual SCSI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: quintela@redhat.com, Alexey Kardashevskiy , agraf@suse.de, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, David Gibson On Fri, 2013-05-31 at 15:58 +1000, Alexey Kardashevskiy wrote: > > And another question (sorry I am not very familiar with terminology but > cc:Ben is :) ) - what happens with indirect requests if migration happened > in the middle of handling such a request? virtio-scsi does not seem to > handle this situation anyhow, it just reconstructs the whole request and > that's it. So Paolo, the crux of the question here is really whether we have any guarantee about the state of the request when this happens (by this I mean a save happening with requests still "in flight") ? IE. Can the request can be at any stage of processing, with the data transfer phase being half way through, or do we somewhat know for sure that the request will *not* have started transferring any data ? This is key, because in the latter case, all we really need to do is save the request itself, and re-parse it on restore as if it was new really (at least from a DMA descriptor perspective). However, if the data transfer is already half way through, we need to somewhat save the state of the data transfer machinery, ie. the position of the "cursor" that follows the guest-provided DMA descriptor list, etc... (which isn't *that* trivial since we have a concept of indirect descriptors and we use pointers to follow them, so we'd probably have to re-walk the whole user descriptors list until we reach the same position). Cheers, Ben.