[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 13/15] scsi: Implement alloc_req_iov callback
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] [PATCH 13/15] scsi: Implement alloc_req_iov callback |
Date: |
Fri, 26 Nov 2010 00:06:57 +0000 |
User-agent: |
KMail/1.13.5 (Linux/2.6.36-trunk-amd64; KDE/4.4.5; x86_64; ; ) |
> I must say I'd like to get rid of the chunking transfer in scsi-disk.
> To have it for scsi-disk only is really pointless, as you can
> potentially send exactly the same commands via scsi-generic.
> So for scsi-generic to work properly qemu need to be able to
> allocate the _entire_ data buffer. And hence qemu _must_ be able to
> allocate the same buffer for the scsi-disk emulation.
> So any malloc space arguments don't really work out here.
>
> By the same reasoning we could remove the chunking altogether;
> any HBA _must_ be capable of issuing the entire data (if issued via
> scsi-generic) even today. So I don't really buy the argument of
> chunking being required for large I/Os.
We've been over this before. Your logic is fundamentally flawed.
In many cases The HBA simply doesn't know where the data is going to go until
after the command has been issued. Issuing the command (which may fail) and
setting up the buffer to receive the data are separate operations, and there
may be guest visible state in between. Even if you assume the initial command
is accepted successfully, the DMA buffer may be submitted in several parts. If
the device response does not full all these parts then we should not be
accessing the unused ones. And this is assuming your HBA is DMA capable to
start with - a USB mass storage device almost certainly isn't.
Even if you do know the full DMA buffer ahead of time, there's no guarantee
that you'll actually be able to map it all at once. You have to assume that
bounce buffers are required, and only a small chunk of the ram can be mapped
at any point.
Combine this with the fact that the guest may submit arbitrarily large
requests and you need some form of chunking. IIRC the passthrough support
ignores the linux interface already restricts you to relatively small
requests.
Paul
- [Qemu-devel] [PATCH 02/15] scsi: Return SAM status codes, (continued)
- [Qemu-devel] [PATCH 02/15] scsi: Return SAM status codes, Hannes Reinecke, 2010/11/24
- [Qemu-devel] [PATCH 01/15] scsi: Increase the number of possible devices, Hannes Reinecke, 2010/11/24
- [Qemu-devel] [PATCH 08/15] scsi-disk: Allocate iovec dynamically, Hannes Reinecke, 2010/11/24
- [Qemu-devel] [PATCH 12/15] scsi: Implement 'get_sense' callback, Hannes Reinecke, 2010/11/24
- [Qemu-devel] [PATCH 13/15] scsi: Implement alloc_req_iov callback, Hannes Reinecke, 2010/11/24
[Qemu-devel] [PATCH 04/15] scsi: Move sense handling into the driver, Hannes Reinecke, 2010/11/24
[Qemu-devel] [PATCH 15/15] Make SCSI HBA configurable, Hannes Reinecke, 2010/11/24
[Qemu-devel] [PATCH 10/15] scsi-disk: add data direction checking, Hannes Reinecke, 2010/11/24
[Qemu-devel] [PATCH 09/15] scsi: Use 'SCSIRequest' directly, Hannes Reinecke, 2010/11/24
[Qemu-devel] [PATCH 06/15] scsi: Update sense code handling, Hannes Reinecke, 2010/11/24
[Qemu-devel] [PATCH 11/15] Remove 'bus' argument from SCSI command completion callbacks, Hannes Reinecke, 2010/11/24
[Qemu-devel] [PATCH 14/15] megasas: LSI Megaraid SAS emulation, Hannes Reinecke, 2010/11/24