[Top][All Lists]

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

Re: dma_blk helpers and infinite dma_memory_map retries

From: Paolo Bonzini
Subject: Re: dma_blk helpers and infinite dma_memory_map retries
Date: Wed, 29 Jul 2020 13:43:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0

On 29/07/20 08:04, John Snow wrote:
> Somehow we manage to map 1 byte, and then 0x1000 more bytes (!?),
> but then we can go no further.

This is 1 byte of memory, and then we reach an MMIO area; further maps
are limited to 0x1000 bytes which is the size of the address_space_map
bounce buffer.  The idea is that the bounce buffer is released by
address_space_unmap and DMA proceeds with the next 0x1000 bytes.

> What is the "reschedule" functionality here supposed to be doing? I
> assume we are waiting to see if a mapping succeeds later, but this
> mapping seems like it should never work -- how can we determine the
> difference between a remap that *might* work later and one that will
> never work?

This is the question: what is special about this address_space_map, that
makes it never succeed?  The usual case where address_space_map fails is
simply two or more concurrent users of the bounce buffer, and these
solve by themselves when address_space_unmap calls
cpu_notify_map_clients.  Do we never call address_space_unmap?

> How many times should we try to map a certain range? address_space_map
> warns that scheduling with cpu_register_map_client is only *likely* to
> allow you to succeed.

It should still *eventually* succeed (subject to fairness in execution
of the MapClient bottom halves).  So again the question is why this doesn't.


reply via email to

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