From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:49908)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1UjO90-0006Bn-TL
	for qemu-devel@nongnu.org; Mon, 03 Jun 2013 02:21:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1UjO8w-0005NT-DY
	for qemu-devel@nongnu.org; Mon, 03 Jun 2013 02:21:26 -0400
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <51AC35D4.4090507@redhat.com>
Date: Mon, 03 Jun 2013 08:21:08 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
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>
	<51A87AAA.6080306@ozlabs.ru> <51A87E5B.1030100@redhat.com>
	<1370044871.3928.173.camel@pasglop>
In-Reply-To: <1370044871.3928.173.camel@pasglop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 7/8] pseries: savevm support for PAPR
	virtual SCSI
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: quintela@redhat.com, Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org, agraf@suse.de, qemu-ppc@nongnu.org, David Gibson <david@gibson.dropbear.id.au>

Il 01/06/2013 02:01, Benjamin Herrenschmidt ha scritto:
> On Fri, 2013-05-31 at 12:41 +0200, Paolo Bonzini wrote:
> 
>> It may be halfway through, but it is always restarted on the destination.
> 
> "restarted" as in the whole transfer is restarted if any right ? So we
> can essentially consider as a new request for which we just did
> scsi_req_enqueue() ?
> 
> IE. We don't do direct DMA to guest pages just yet (we still do copies)
> so basically our process is:
> 
>  1- Obtain request from guest
>  2- Queue it (scsi_req_enqueue)
>  3- No transfer -> go away (completion is called)
>  4- Pre-process user descriptors (check desc type direct vs indirect,
>     position our "cursor" walking them etc....)
>  5- scsi_req_continue()
>     .../... loop of callbacks & transfer
> 
> Now from what you say, I assume that regardless of the point where
> the request was, when we "resume" it will always be at step 4 ?
> 
> IE. I can just pre-process the descriptors again ? (I actually need
> to transfer them again from the guest since I suspect I clobber them
> at the very least due to byteswap) and call scsi_req_continue() and
> assume the transfer (if any) started from the beginning ?

Yes.  Unless the spec somehow lets the guest figure out the point at
which the whole chain has been pre-processed, and lets the guest modify
the chain at this point.  But if that's not the case, you can do that.
Memory has already been loaded when load_request runs.

Paolo