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

[Gerd Hoffmann <kraxel@redhat.com>]

On 11/16/09 19:53, Paul Brook wrote:
>> We can also limit the amout of host memory we allow the guest to
>> consume, so uncooperative guests can't push the host into swap.  This is
>> not implemented today, indicating that it hasn't been a problem so far.
>
> Capping the amount of memory required for a transfer *is* implemented, in both
> LSI and virtio-blk.  The exception being SCSI passthrough where the kernel API
> makes it impossible.

I was talking about scsi-generic.  There is no option to reject 
excessive large requests, and it was no problem so far.

>>    And with zerocopy it will be even less a problem as we don't need host
>> memory to buffer the data ...
>
> zero-copy isn't possible in many cases. You must handle the other cases
> gracefully.

I havn't yet found a guest OS where lsi can't do zerocopy.
Name one where it doesn't work and I'll have a look.

>>> Disconnecting on the first DMA request (after switching to a data phase
>>> and transferring zero bytes) is bizarre behavior, but probably allowable.
>>
>> The new lsi code doesn't.  The old code could do that under certain
>> circumstances.  And what is bizarre about that?  A real hard drive will
>> most likely do exactly that on reads (unless it has the data cached and
>> can start the transfer instantly).
>
> No. The old code goes directly from the command phase to the message
> (disconnect) phase.

Hmm, well.  It switches from DI / DO to MI before the guest runs again 
so the guest will not notice the switch ...

>>> However by my reading DMA transfers must be performed synchronously by
>>> the SCRIPTS engine, so you need to do a lot of extra checking to prove
>>> that you can safely continue execution without actually performing the
>>> transfer.
>>
>> I'll happily add a 'strict' mode which does data transfers synchronously
>> in case any compatibility issues show up.
>>
>> Such a mode would be slower of course.  We'll have to either do the I/O
>> in lots of little chunks or loose zerocopy.  Large transfers + memcpy is
>> probably the faster option.
>
> But as you agreed above, large transfers+memcpy is not a realistic option
> because it can have excessive memory requirements.

This "large" refers to normal request sizes (which are large compared to 
page-sized scatter list entries).  Having a 64k request submitted as a 
single I/O, then memcpy is most likely faster than submitting 16 I/O 
requests with 4k each one after another.  Buffering would be no problem 
here.

But I still don't expect problems with zerocopy though.  And zerocopy 
hasn't noticable host memory requirements even on excessive large requests.

cheers,
   Gerd