Re: [Qemu-devel] [sneak preview] major scsi overhaul

[Gerd Hoffmann <kraxel@redhat.com>]

On 11/11/09 15:13, Paul Brook wrote:
>> The current qemu code *does* cache the response.  scsi-disk caps the
>> buffer at 128k (which is big enough for any request I've seen in my
>> testing).  scsi-generic has no cap.
>
> That cap is important.
> For scsi-generic you probably don't have a choice because of the way the
> kernel interface works.

Exactly.  And why is the cap important for scsi-disk if scsi-generic 
does fine without?

>> scsi-disk: dma_bdrv_{read,write} will split it into smaller chunks if
>> needed.
>
> You seem to be assuming the HBA knows where it's going to put the data before
> it issues the command.  This is not true (see blow).

You are talking about a real HBA I guess?

>> lsi (only one in-tree with TCQ support) works like this:
>>
>> - allocate + parse scsi command.        scsi_req_get+scsi_req_parse
>> - continue script processing, collect
>>     DMA addresses and stick them into
>>     a scatter list until it is complete.
>> - queue command and disconnect.
>> - submit I/O to the qemu block layer    scsi_req_sgl
>>
>> *can process more scsi commands here*
>>
>> - when I/O is finished reselect tag
>> - return status, release request.       scsi_req_put
>
> I'm pretty sure this is wrong,

This describes what the lsi emulation does with my patches applied.

> and what actually happens is:
>
> 1) Wait for device to reconnect (goto 5), or commands from host (goto 2).
>
> 2) SCRIPTS connect to device, and send command.
> 3) If device has data immediately (metadata command) then goto 6
> 4) Device disconnects. goto 1
>
> 5) Device has data ready, and reconnects
> 6) SCRIPTS locate the next DMA block for this command, and initiate a (linear)
> DMA transfer.
> 7) DATA is transferred. Note that DMA stalls the SCRIPTS processor until the
> transfer completes.
> 8) If the device still has data then goto 6.
> 9) If the device runs out of data before the command completes then goto 3.
> 10) Command complete. goto 1

This is what a real HBA does.

> Note that the IO command is parsed at stage 2, but the data transfer is not
> requested until stage 6. i.e. after the command has partially completed. This
> window between issue and data transfer is where other commands are issued.

Or when the device disconnects again in the middle of a transfer.

> The only way to make your API work is to skip straight from step 3 to step 6,
> which effectively looses the command queueing capability.

It doesn't.  The disconnect and thus the opportunity to submit more 
commands while the device is busy doing the actual I/O is there.

> It may be that it's
> hard/impossible to get both command queueing and zero-copy.

I have it working.

cheers,
   Gerd