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

[Gerd Hoffmann]

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