On 09/09/2011 03:34 PM, Kevin Wolf wrote:
So the release that we avoid is the release in the callback that may or
may not be called indirectly by bdrv_aio_cancel. We always call
dma_complete at the end of dma_aio_cancel so that it will be properly freed.
In fact it may be worse than just the qe
Am 09.09.2011 15:12, schrieb Paolo Bonzini:
> On 09/09/2011 02:59 PM, Kevin Wolf wrote:
Also, I think it should be -EIO instead of -ENOMEM (even though it
doesn't make any difference if we don't call the callback)
>>>
>>> If I understood the code correctly, dbs->io_func can only fail if i
On 09/09/2011 02:59 PM, Kevin Wolf wrote:
Also, I think it should be -EIO instead of -ENOMEM (even though it
doesn't make any difference if we don't call the callback)
If I understood the code correctly, dbs->io_func can only fail if it
fails to get an AIOCB, which is basically out-of-memory.
Am 09.09.2011 14:43, schrieb Paolo Bonzini:
>>> @@ -120,9 +132,8 @@ static void dma_bdrv_cb(void *opaque, int ret)
>>> dbs->acb = dbs->io_func(dbs->bs, dbs->sector_num, &dbs->iov,
>>> dbs->iov.size / 512, dma_bdrv_cb, dbs);
>>> if (!dbs->acb) {
>>> -dm
> > @@ -120,9 +132,8 @@ static void dma_bdrv_cb(void *opaque, int ret)
> > dbs->acb = dbs->io_func(dbs->bs, dbs->sector_num, &dbs->iov,
> > dbs->iov.size / 512, dma_bdrv_cb, dbs);
> > if (!dbs->acb) {
> > -dma_bdrv_unmap(dbs);
> > -qemu_iovec_d
Am 07.09.2011 17:21, schrieb Paolo Bonzini:
> This fixes various problems with completion/cancellation:
>
> * If DMA encounters a bounce buffer conflict, and the DMA operation is
> canceled before the bottom half fires, bad things happen.
>
> * memory is not unmapped after cancellation, again cau
This fixes various problems with completion/cancellation:
* If DMA encounters a bounce buffer conflict, and the DMA operation is
canceled before the bottom half fires, bad things happen.
* memory is not unmapped after cancellation, again causing problems
when doing DMA to I/O areas
* cancellatio
