From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=50667 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PLY4s-0004o2-Fi
	for qemu-devel@nongnu.org; Thu, 25 Nov 2010 04:25:19 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1PLY4r-0000WJ-Cf
	for qemu-devel@nongnu.org; Thu, 25 Nov 2010 04:25:18 -0500
Received: from mx1.redhat.com ([209.132.183.28]:50891)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1PLY4r-0000WC-3q
	for qemu-devel@nongnu.org; Thu, 25 Nov 2010 04:25:17 -0500
Message-ID: <4CEE2B6E.40102@redhat.com>
Date: Thu, 25 Nov 2010 10:25:02 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH] scsi-generic: bugfixes for 'SCSIRequest'
	conversion
References: <1290586723-8724-1-git-send-email-nab@linux-iscsi.org>		<4CECD36E.50401@suse.de>
	<4CECD50F.9060501@redhat.com>		<4CECE609.7080600@suse.de>
	<4CECEA2A.40008@redhat.com>		<4CECED12.5020109@suse.de>
	<1290674774.32570.106.camel@pasglop>		<4CEE2343.3090505@redhat.com>
	<1290675704.32570.114.camel@pasglop> <4CEE2724.6000801@suse.de>
In-Reply-To: <4CEE2724.6000801@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.nongnu.org/archive/html/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: Kevin Wolf <kwolf@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, "Nicholas A. Bellinger" <nab@linux-iscsi.org>, Stefan Hajnoczi <stefanha@gmail.com>, Paolo Bonzini <pbonzini@redhat.com>, linux-iscsi-target-dev@googlegroups.com

>> Right now, I've somewhat come up with:
>>
>>    - client request occurs
>>    - call device send_command()
>>    - if result is 0, assume my complete() was called with
>>      SCSI_REASON_DONE
>>    - else, use sign of result for transfer direction, store the
>>      absolute value as the total expected transfer len and call
>>      the device scsi_data_read()/write() and wait for complete()
>>    - when complete() is called:
>>      - if SCSI_REASON_DONE, complete client request
>>      - else perform the client "DMA" for "arg" bytes
>>      - call the device scsi_data_read()/write() again
>>
> No, this is exactly as I'm expecting the SCSI layer to work.

Yes.

> So from the light of this the patch to scsi-generic is valid.

Yes.

> And it really looks like papering over a bug in the lsi HBA code.

Indeed.  If the patch breaks lsi I'd agree that it is lsi's fault. 
Anyone tested whenever current upstream lsi actually breaks with the 
patch applied?

I've attempted to convert lsi to use iovecs a while ago, and *that* 
version definitively had problems with short transfers, so maybe this is 
a leftover from those days where scsi hacking was based on that branch ...

cheers,
   Gerd