Re: dma_blk helpers and infinite dma_memory_map retries

[John Snow]

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.
>
> Paolo

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