Re: [Qemu-devel] [PATCH 7/8] pseries: savevm support for PAPR virtual SCSI

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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 ?

> virtio-scsi parses the whole descriptor chain upfront and sends the
> guest addresses in the migration stream.
> 
> > Is not it the same QEMU thread which handles hcalls and QEMU console
> > commands so the migration cannot stop parsing/handling a vscsi_req?
> 
> The VM is paused and I/O is flushed at the point when the reqs are sent.
>  That's why you couldn't get a pending request.  Only failed requests
> remain in queue.

Ben.