From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NA9T8-0000CT-38 for qemu-devel@nongnu.org; Mon, 16 Nov 2009 16:50:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NA9T3-0000Ak-FG for qemu-devel@nongnu.org; Mon, 16 Nov 2009 16:50:41 -0500 Received: from [199.232.76.173] (port=47934 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NA9T3-0000Af-Bi for qemu-devel@nongnu.org; Mon, 16 Nov 2009 16:50:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:13520) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NA9T2-0005cT-EB for qemu-devel@nongnu.org; Mon, 16 Nov 2009 16:50:37 -0500 Message-ID: <4B01C921.80902@redhat.com> Date: Mon, 16 Nov 2009 22:50:25 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul References: <4AF4ACA5.2090701@redhat.com> <200911111638.31288.paul@codesourcery.com> <4B017F46.4030700@redhat.com> <200911161853.34668.paul@codesourcery.com> In-Reply-To: <200911161853.34668.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On 11/16/09 19:53, Paul Brook wrote: >> We can also limit the amout of host memory we allow the guest to >> consume, so uncooperative guests can't push the host into swap. This is >> not implemented today, indicating that it hasn't been a problem so far. > > Capping the amount of memory required for a transfer *is* implemented, in both > LSI and virtio-blk. The exception being SCSI passthrough where the kernel API > makes it impossible. I was talking about scsi-generic. There is no option to reject excessive large requests, and it was no problem so far. >> And with zerocopy it will be even less a problem as we don't need host >> memory to buffer the data ... > > zero-copy isn't possible in many cases. You must handle the other cases > gracefully. I havn't yet found a guest OS where lsi can't do zerocopy. Name one where it doesn't work and I'll have a look. >>> Disconnecting on the first DMA request (after switching to a data phase >>> and transferring zero bytes) is bizarre behavior, but probably allowable. >> >> The new lsi code doesn't. The old code could do that under certain >> circumstances. And what is bizarre about that? A real hard drive will >> most likely do exactly that on reads (unless it has the data cached and >> can start the transfer instantly). > > No. The old code goes directly from the command phase to the message > (disconnect) phase. Hmm, well. It switches from DI / DO to MI before the guest runs again so the guest will not notice the switch ... >>> However by my reading DMA transfers must be performed synchronously by >>> the SCRIPTS engine, so you need to do a lot of extra checking to prove >>> that you can safely continue execution without actually performing the >>> transfer. >> >> I'll happily add a 'strict' mode which does data transfers synchronously >> in case any compatibility issues show up. >> >> Such a mode would be slower of course. We'll have to either do the I/O >> in lots of little chunks or loose zerocopy. Large transfers + memcpy is >> probably the faster option. > > But as you agreed above, large transfers+memcpy is not a realistic option > because it can have excessive memory requirements. This "large" refers to normal request sizes (which are large compared to page-sized scatter list entries). Having a 64k request submitted as a single I/O, then memcpy is most likely faster than submitting 16 I/O requests with 4k each one after another. Buffering would be no problem here. But I still don't expect problems with zerocopy though. And zerocopy hasn't noticable host memory requirements even on excessive large requests. cheers, Gerd