Re: [Qemu-devel] Re: [PATCH] scsi-generic: bugfixes for 'SCSIRequest' conversion

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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