From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiMmN-0006GA-WE for qemu-devel@nongnu.org; Fri, 31 May 2013 06:41:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UiMmM-0003BD-V7 for qemu-devel@nongnu.org; Fri, 31 May 2013 06:41:51 -0400 Message-ID: <51A87E5B.1030100@redhat.com> Date: Fri, 31 May 2013 12:41:31 +0200 From: Paolo Bonzini 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> In-Reply-To: <51A87AAA.6080306@ozlabs.ru> 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: Alexey Kardashevskiy Cc: quintela@redhat.com, agraf@suse.de, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, David Gibson Il 31/05/2013 12:25, Alexey Kardashevskiy ha scritto: > 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). It may be halfway through, but it is always restarted on the destination. 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. Paolo