From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NDZgG-00011V-SP
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 03:26:24 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NDZgC-0000xb-Ba
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 03:26:24 -0500
Received: from [199.232.76.173] (port=52725 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NDZgC-0000xY-59
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 03:26:20 -0500
Received: from mx1.redhat.com ([209.132.183.28]:6903)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1NDZgB-0005Hv-NX
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 03:26:20 -0500
Message-ID: <4B0E3B90.5080001@redhat.com>
Date: Thu, 26 Nov 2009 09:25:52 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
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>
In-Reply-To: <4B0E2EC8.7040309@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Hannes Reinecke <hare@suse.de>
Cc: Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

   Hi,

>> 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.
>>
>> 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.

I'll try.

> Should be straightforward to implement, one would assume.

The infrastructure and the HBAs have to handle that already.  It 
frequently happens with MODE SENSE for example (guest passing a 256 byte 
buffer and we have less data to fill in).  So it should be easy.

> 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.

Hmm, I don't think so.  SG_IO just returns EINVAL.

cheers,
   Gerd