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

[Paul Brook <paul@codesourcery.com>]

On Monday 16 November 2009, Gerd Hoffmann wrote:
> On 11/11/09 17:38, Paul Brook wrote:
> >>> 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?
> >
> > With scsi-generic you're at the mercy of what the kernel API gives you,
> > and if the guest hardware/OS isn't cooperative then you loose.
> 
> The guest will loose with unreasonable large requests.  qemu_malloc() ->
> oom() -> abort() -> guest is gone.

Exactly. This lossage is not acceptable.

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

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

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

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

Paul