From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NDcPG-0008PX-0Y
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 06:21:02 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NDcPB-0008MC-2V
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 06:21:01 -0500
Received: from [199.232.76.173] (port=36586 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NDcPA-0008Lv-S1
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 06:20:56 -0500
Received: from cantor.suse.de ([195.135.220.2]:58702 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 <hare@suse.de>) id 1NDcPA-0007Ps-FE
	for qemu-devel@nongnu.org; Thu, 26 Nov 2009 06:20:56 -0500
Message-ID: <4B0E6496.1060203@suse.de>
Date: Thu, 26 Nov 2009 12:20:54 +0100
From: Hannes Reinecke <hare@suse.de>
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> <4B0E5EFD.6060701@suse.de>
	<4B0E60AF.9000508@redhat.com>
In-Reply-To: <4B0E60AF.9000508@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Gerd Hoffmann <kraxel@redhat.com>
Cc: Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

Gerd Hoffmann wrote:
> On 11/26/09 11:57, Hannes Reinecke wrote:
>> 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.
>=20
> Except they don't.
>=20
> /me looks at drivers/scsi/sd.c:sd_done()
>=20
> I can't see any sane way to tell linux that the request was too big.
>=20
residuals is the key:

drivers/scsi/scsi.c:scsi_finish_command()


	good_bytes =3D scsi_bufflen(cmd);
        if (cmd->request->cmd_type !=3D REQ_TYPE_BLOCK_PC) {
		int old_good_bytes =3D good_bytes;
		drv =3D scsi_cmd_to_driver(cmd);
		if (drv->done)
			good_bytes =3D drv->done(cmd);
		/*
		 * USB may not give sense identifying bad sector and
		 * simply return a residue instead, so subtract off the
		 * residue if drv->done() error processing indicates no
		 * change to the completion length.
		 */
		if (good_bytes =3D=3D old_good_bytes)
			good_bytes -=3D scsi_get_resid(cmd);
	}
	scsi_io_completion(cmd, good_bytes);

and in

drivers/scsi/scsi_lib.c:scsi_io_completion()

	/*
	 * A number of bytes were successfully read.  If there
	 * are leftovers and there is some kind of error
	 * (result !=3D 0), retry the rest.
	 */
	if (scsi_end_request(cmd, error, good_bytes, result =3D=3D 0) =3D=3D NUL=
L)
		return;


No-one forces us to complete the _entire_ request; just completing
the request partially is perfectly okay as long as we mark it properly.

Cheers,

Hannes
--=20
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg
GF: Markus Rex, HRB 16746 (AG N=FCrnberg)