From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiZGI-0008Pg-TB for qemu-devel@nongnu.org; Fri, 31 May 2013 20:01:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UiZGE-0006b9-Bf for qemu-devel@nongnu.org; Fri, 31 May 2013 20:01:34 -0400 Message-ID: <1370044871.3928.173.camel@pasglop> From: Benjamin Herrenschmidt Date: Sat, 01 Jun 2013 10:01:11 +1000 In-Reply-To: <51A87E5B.1030100@redhat.com> 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> 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 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.