From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NA5wK-0002pu-6X for qemu-devel@nongnu.org; Mon, 16 Nov 2009 13:04:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NA5wE-0002ol-5a for qemu-devel@nongnu.org; Mon, 16 Nov 2009 13:04:35 -0500 Received: from [199.232.76.173] (port=37631 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NA5wC-0002oM-Bp for qemu-devel@nongnu.org; Mon, 16 Nov 2009 13:04:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45833) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NA5wB-0004NL-Nw for qemu-devel@nongnu.org; Mon, 16 Nov 2009 13:04:28 -0500 Message-ID: <4B017F46.4030700@redhat.com> Date: Mon, 16 Nov 2009 17:35:18 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul References: <4AF4ACA5.2090701@redhat.com> <200911111413.09320.paul@codesourcery.com> <4AFAD7A8.70707@redhat.com> <200911111638.31288.paul@codesourcery.com> In-Reply-To: <200911111638.31288.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/11/09 17:38, Paul Brook wrote: >>> That cap is important. >>> For scsi-generic you probably don't have a choice because of the way the >>> kernel interface works. >> >> Exactly. And why is the cap important for scsi-disk if scsi-generic >> does fine without? > > With scsi-generic you're at the mercy of what the kernel API gives you, and if > the guest hardware/OS isn't cooperative then you loose. The guest will loose with unreasonable large requests. qemu_malloc() -> oom() -> abort() -> guest is gone. 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. And with zerocopy it will be even less a problem as we don't need host memory to buffer the data ... >> It doesn't. The disconnect and thus the opportunity to submit more >> commands while the device is busy doing the actual I/O is there. > > 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). > 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. >>> It may be that it's >>> hard/impossible to get both command queueing and zero-copy. >> >> I have it working. > > More likely you have a nasty hack that happens to work with the Linux drivers. Linux works. Windows XP works. FreeBSD works. More regression testing is planned. Suggestions for other guests which might be sensitive to changes like this? Maybe even some which don't work with the current lsi emulation? > IIUC you're pretending that the DMA completed and eventually disconnecting the > device, assuming that nothing will read that data until the command complete > notification is received. Yes. > Consider the case there the guest transfers the data from a single command in > two blocks, and has the HBA raise an interrupt in-between so that it can start > processing before the command completes. This processing could even be done by > the SCRIPTS engine itself, or a guest could even reuse the buffer for the > second DMA block. In theory you can do all sorts of crazy stuff with the lsi scripts engine, like implementing a ext2 filesystem driver. In practice I expect guests will use the scripts engine only for stuff which is also supported by other scsi controllers. cheers, Gerd