[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [sneak preview] major scsi overhaul
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] [sneak preview] major scsi overhaul |
Date: |
Wed, 11 Nov 2009 16:38:31 +0000 |
User-agent: |
KMail/1.12.2 (Linux/2.6.30-2-amd64; KDE/4.3.2; x86_64; ; ) |
>> 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. With scsi-disk we can
do significantly better.
> > 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.
Disconnecting on the first DMA request (after switching to a data phase and
transferring zero bytes) is bizarre behavior, but probably allowable.
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.
> > It may be that it's
> > hard/impossible to get both command queueing and zero-copy.
>
> I have it working.
More likely you have a nasty hack that happens to work with the Linux drivers.
IIUC you're pretending that the DMA completed and eventually disconnecting the
device, assuming that nothing will read that data until the command complete
notification is received.
Consider the case there the guest transfers the data from a single command in
two blocks, and has the HBA raise an interrupt in-between so that it can start
processing before the command completes. This processing could even be done by
the SCRIPTS engine itself, or a guest could even reuse the buffer for the
second DMA block.
Paul
Re: [Qemu-devel] [sneak preview] major scsi overhaul, Paul Brook, 2009/11/10
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Gerd Hoffmann, 2009/11/11
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Paul Brook, 2009/11/11
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Gerd Hoffmann, 2009/11/11
- Re: [Qemu-devel] [sneak preview] major scsi overhaul,
Paul Brook <=
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Gerd Hoffmann, 2009/11/16
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Paul Brook, 2009/11/16
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Gerd Hoffmann, 2009/11/16
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Gerd Hoffmann, 2009/11/24
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Paul Brook, 2009/11/24
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Gerd Hoffmann, 2009/11/25
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Hannes Reinecke, 2009/11/26
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Gerd Hoffmann, 2009/11/26
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Hannes Reinecke, 2009/11/26
- Re: [Qemu-devel] [sneak preview] major scsi overhaul, Gerd Hoffmann, 2009/11/26