[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: John Snow
Subject: Re: dma_blk helpers and infinite dma_memory_map retries
Date: Wed, 29 Jul 2020 10:26:42 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 7/29/20 7:43 AM, Paolo Bonzini wrote:
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?

I had assumed naively that since the mapping was starting at 0xffffffff and this is the 32bit emulator that we had just run off the end of the universe ...

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.


OK, I'll look a little deeper into how address_space_map itself works.

reply via email to

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