From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDc2A-0002xC-Ly for qemu-devel@nongnu.org; Thu, 26 Nov 2009 05:57:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDc25-0002sW-AS for qemu-devel@nongnu.org; Thu, 26 Nov 2009 05:57:09 -0500 Received: from [199.232.76.173] (port=33104 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDc24-0002rc-L5 for qemu-devel@nongnu.org; Thu, 26 Nov 2009 05:57:04 -0500 Received: from cantor2.suse.de ([195.135.220.15]:53843 helo=mx2.suse.de) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDc24-0004cU-2S for qemu-devel@nongnu.org; Thu, 26 Nov 2009 05:57:04 -0500 Message-ID: <4B0E5EFD.6060701@suse.de> Date: Thu, 26 Nov 2009 11:57:01 +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> <4B0E2EC8.7040309@suse.de> <4B0E3B90.5080001@redhat.com> In-Reply-To: <4B0E3B90.5080001@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: > Hi, >=20 >>> Answering large requests with "Illegal request, Invalid field in CDB" >>> doesn't makes linux try smaller requests, instead it reports I/O erro= rs >>> to the syslog. >>> >>> 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. >=20 > I'll try. >=20 >> Should be straightforward to implement, one would assume. >=20 > The infrastructure and the HBAs have to handle that already. It > frequently happens with MODE SENSE for example (guest passing a 256 byt= e > buffer and we have less data to fill in). So it should be easy. >=20 >> 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. >=20 > Hmm, I don't think so. SG_IO just returns EINVAL. >=20 Yes, but we can hook into scsi_generic_map() to cap the resulting iovec to the limits of the underlying block device. Then we submit an iovec which matches the capabilities of the underlying device. Of course we should take care to update the resulting xferlen values to match the actualy submitted data, but that should be easily done. Then the guest would see a partial request and retry the remainder of the request, which (possibly after some iterations) would result in all data transferred, albeit at a lower speed. 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)