From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TinYR-0004eb-2o for qemu-devel@nongnu.org; Wed, 12 Dec 2012 09:45:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TinYJ-0002JK-Mq for qemu-devel@nongnu.org; Wed, 12 Dec 2012 09:44:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:63929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TinYJ-0002JB-1B for qemu-devel@nongnu.org; Wed, 12 Dec 2012 09:44:51 -0500 Date: Wed, 12 Dec 2012 16:47:58 +0200 From: "Michael S. Tsirkin" Message-ID: <20121212144758.GF15555@redhat.com> References: <20121212105101.GA6461@redhat.com> <20121212135050.GC16270@stefanha-thinkpad.redhat.com> <50C88E53.4080200@redhat.com> <20121212143038.GD15555@redhat.com> <50C8965A.7020004@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50C8965A.7020004@redhat.com> Subject: Re: [Qemu-devel] [PATCHv2] virtio: verify that all outstanding buffers are flushed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Anthony Liguori , Stefan Hajnoczi , Rusty Russell , qemu-devel@nongnu.org, Avi Kivity , Stefan Hajnoczi On Wed, Dec 12, 2012 at 03:36:10PM +0100, Paolo Bonzini wrote: > Il 12/12/2012 15:30, Michael S. Tsirkin ha scritto: > > > Same for virtio-scsi. Each request in that case is sent as part of the > > > SCSIDevice that it refers to, via callbacks in SCSIBusInfo. > > It is in virtio_scsi_load_request. > > > Looks like this will leak ring entries. > > > > All I see is: virtio_scsi_load calling virtio_load. > > When the loading side will get last avail index it > > will assume all requests up to that value have > > completed, so it will never put the missing heads > > in the used ring. > > Ok, so we need some API for virtio-{blk,scsi} to communicate back the > indexes of in-flight requests to virtio. The indexes are known from the > VirtQueueElement, so that's fine. > > Even better would be a virtio_save_request/virtio_load_request API... > > Paolo So you are saying this is a bug then? Great. This is exactly what the assert above is out there to catch. And you really can't fix it without breaking migration compatibility. As step 1, I think we should just complete all outstanding requests when VM stops. Yes it means you can't do the retry hack after migration but this is hardly common scenario. -- MST