|
|
Stefano Stabellini wrote:
Avi Kivity wrote:
If cpu_physical_memory_map() returns NULL, then dma-helpers.c will stop
collecting sg entries and submit the I/O. Tuning that will control how
vectored requests are submitted.
I understand your suggestion now, something like:
---
diff --git a/dma-helpers.c b/dma-helpers.c
index 96a120c..6c43b97 100644
--- a/dma-helpers.c
+++ b/dma-helpers.c
@@ -96,6 +96,11 @@ static void dma_bdrv_cb(void *opaque, int ret)
while (dbs->sg_cur_index < dbs->sg->nsg) {
cur_addr = dbs->sg->sg[dbs->sg_cur_index].base + dbs->sg_cur_byte;
cur_len = dbs->sg->sg[dbs->sg_cur_index].len - dbs->sg_cur_byte;
+ if (dbs->iov.size + cur_len > DMA_LIMIT) {
+ cur_len = DMA_LIMIT - dbs->iov.size;
+ if (cur_len <= 0)
+ break;
+ }
mem = cpu_physical_memory_map(cur_addr, &cur_len, !dbs->is_write);
if (!mem)
break;
---
would work for me.
However it is difficult to put that code inside cpu_physical_memory_map
since I don't have any reference to link together all the mapping
requests related to the same dma transfer.
It would be fine here, but see below.
If you problem is specifically with the bdrv_aio_rw_vector bounce
buffer, then note that this is a temporary measure until vectored aio is
in place, through preadv/pwritev and/or linux-aio IO_CMD_PREADV. You
should either convert to that when it is merged, or implement request
splitting in bdrv_aio_rw_vector.
Can you explain your problem in more detail?
My problem is that my block driver has a size limit for read and write
operations.
Then I think the place to split the requests is in your block format
driver, not the generic code. If you run with one device using the
limited block format driver, and the other device using another,
unlimited block format driver, then the second device would be limited
by the first device's limitation.
I realize your use case will probably not trigger this, but it does
indicate you're limiting at the wrong layer. It places the burden on
all callers of block format drivers instead of centralizing it.
When preadv/pwritev are in place I could limit the transfer size
directly in raw_aio_preadv\pwritev but I would also have to update the
iovector size field to reflect that and I think is a little bit ugly.
Just copy the iovec for each sub-request.
--
error compiling committee.c: too many arguments to function
|
|