From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDYp6-0006Ao-6Y for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:31:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDYp1-000698-Ts for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:31:27 -0500 Received: from [199.232.76.173] (port=38081 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDYp1-000695-O2 for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:31:23 -0500 Received: from cantor.suse.de ([195.135.220.2]:50111 helo=mx1.suse.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NDYp1-0001gf-6B for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:31:23 -0500 Message-ID: <4B0E2EC8.7040309@suse.de> Date: Thu, 26 Nov 2009 08:31:20 +0100 From: Hannes Reinecke MIME-Version: 1.0 Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul References: <4AF4ACA5.2090701@redhat.com> <200911161853.34668.paul@codesourcery.com> <4B0BCAA1.3090400@redhat.com> <200911241351.03650.paul@codesourcery.com> <4B0D5D36.6080100@redhat.com> In-Reply-To: <4B0D5D36.6080100@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Paul Brook , qemu-devel@nongnu.org Gerd Hoffmann wrote: > On 11/24/09 14:51, Paul Brook wrote: >> On Tuesday 24 November 2009, Gerd Hoffmann wrote: >>> On 11/16/09 19:53, Paul Brook wrote: >>>> 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. >>> >>> Well. Figured while doing more testing: The allowed request size is >>> limited by the kernel, so scsi-generic requests larger than (currentl= y) >>> 128k fail. >>> >>> Now, how to handle *that*? Is there some way to signal to the guest >>> that the request was to big? >> >> Same as real hardware. Probably also want to populate the Block >> Limits VPD >> page appropriately >=20 > Some experiements later. >=20 > Linux reads the block limits vpd, but seems to ignore the hard limit. >=20 Ah. Maybe we should fix that up then ... > Answering large requests with "Illegal request, Invalid field in CDB" > doesn't makes linux try smaller requests, instead it reports I/O errors > to the syslog. >=20 > Hmm. > Can't we just put residuals to good use here? Ie finish up the request up to the size we can handle, and return the original request with the transfer size set correctly. Then the SCSI stack of the guest should retry the leftovers, which then we should be able to handle. Or redo from start until we are able to. Should be straightforward to implement, one would assume. And we could probably encapsulate it entirely within the bdrv as don't actually need to expose those limits when the block driver layer is handling it correctly. Cheers, Hannes --=20 Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg GF: Markus Rex, HRB 16746 (AG N=C3=BCrnberg)