From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40585 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PT37D-00079E-UM for qemu-devel@nongnu.org; Wed, 15 Dec 2010 20:58:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PT37C-0003BP-Lu for qemu-devel@nongnu.org; Wed, 15 Dec 2010 20:58:43 -0500 Received: from gate.crashing.org ([63.228.1.57]:52640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PT37C-0003B2-Em for qemu-devel@nongnu.org; Wed, 15 Dec 2010 20:58:42 -0500 Subject: Re: [Qemu-devel] Re: [PATCH] scsi-generic: bugfixes for 'SCSIRequest' conversion From: Benjamin Herrenschmidt In-Reply-To: <4CECED12.5020109@suse.de> 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> Content-Type: text/plain; charset="UTF-8" Date: Thu, 16 Dec 2010 12:58:31 +1100 Message-ID: <1292464711.16694.514.camel@pasglop> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hannes Reinecke Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel , "Nicholas A. Bellinger" , Gerd Hoffmann , Paolo Bonzini , linux-iscsi-target-dev@googlegroups.com > > The commit message of this commit says it's a workaround for a problem > > with lsi: > > > >> - when a read is aborted due to a mark/EOF/EOD/EOM, the len reported to > >> controller can be 0. LSI controller emulation doesn't know how to manage > >> this. A workaround found is to call the completion routine with > >> SCSI_REASON_DONE just after calling it with SCSI_REASON_DATA with len=0. > > > > Are you sure that it's not needed any more? > > > Don't ask me. I didn't do the patch, and my knowledge of lsi HBA > internals is scanty. > Nic, can you comment here? Back to this topic... On my current WIP code, currently based on qemu upstream commit f711df67d611e4762966a249742a5f7499e19f99, I've just observed the following behaviour: Use -cdrom /dev/cdrom (which points to /dev/sr0) No disk in the drive, scsi-disk kicks in. test-unit-ready properly says there's no medium, so far so good. Now, my (buggy) guest code tries to do a READ_10. At this point, qemu hangs. What happens is that my scsi complete callback get called with reason 1 (DATA) and arg 0. I then perform no data copy, and call back sdev->info->read_data() which eventually calls me back again with reason 1 and arg 0, etc... in a loop. I haven't had a chance yet to look at what's happening in the guts of scsi-disk, but here, either I'm supposed to special case DATA with 0 bytes requested in my HBA driver, or there's a bug in scsi-disk. I can work around it by doing a cancel_io in that case and then completing the request is if reason had been 0 (DONE) but that's of course just a band-aid. I'll let you know what I find out when I get a chance to look at this again (hopefully soon). Cheers, Ben.