qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul
Date: Mon, 16 Nov 2009 22:50:25 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]