From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiMWy-0000eQ-Nz for qemu-devel@nongnu.org; Fri, 31 May 2013 06:25:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UiMWw-0004yD-Um for qemu-devel@nongnu.org; Fri, 31 May 2013 06:25:56 -0400 Received: from mail-pb0-x229.google.com ([2607:f8b0:400e:c01::229]:45116) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiMWw-0004xp-OL for qemu-devel@nongnu.org; Fri, 31 May 2013 06:25:54 -0400 Received: by mail-pb0-f41.google.com with SMTP id xb12so1992807pbc.28 for ; Fri, 31 May 2013 03:25:53 -0700 (PDT) Message-ID: <51A87AAA.6080306@ozlabs.ru> Date: Fri, 31 May 2013 20:25:46 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 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> <1369994875.3928.137.camel@pasglop> In-Reply-To: <1369994875.3928.137.camel@pasglop> Content-Type: text/plain; charset=KOI8-R 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: Benjamin Herrenschmidt Cc: quintela@redhat.com, agraf@suse.de, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Paolo Bonzini , David Gibson On 05/31/2013 08:07 PM, Benjamin Herrenschmidt wrote: > 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). Is not it the same QEMU thread which handles hcalls and QEMU console commands so the migration cannot stop parsing/handling a vscsi_req? -- Alexey