Re: [Qemu-devel] [PATCH 2/5] Add map client retry notification

[Anthony Liguori]

Ian Jackson wrote:
> Avi Kivity writes ("[Qemu-devel] [PATCH 2/5] Add map client retry 
> notification"):
>   
> > The target memory mapping API may fail if the bounce buffer resources
> > are exhausted.  Add a notification mechanism to allow clients to retry
> > the mapping operation when resources become available again.
> >     
>
> Does this API not suffer from the potential deadlock described by
> Anthony ?
>
> Imagine that for some reason bounce buffers are in use.  If we have a
> client which wants to do a single writev on a tap device it will even
> deadlock by itself:
>
>   map(<block 0>) succeeds
>   map(<block 1>) fails, NULL
>   register_map_client
>
> but the callback will never happen because the client is effectively
> waiting for itself to release its own mapping.
>   

Yes, a client is not allowed to do this.  To put it another way (and 
perhaps this needs to be documented), register_map_client can only be 
used safely if a client unmaps all of it's existing mappings.

> Since callers cannot assume that they can map more than one range at
> once (since there's only one bounce buffer), any caller which needs to
> do scatter-gather (like a tap device, as Anthony points out) needs to
> invent its own bounce buffers.  That seems like a waste of effort.
>   

It needs to be able to fall back to something like cpu_physical_memory_rw.

> There should be a single bounce buffer fallback mechanism, and it
> should be sufficiently powerful that it can be used for tap devices,
> which means that the calling device emulation must present a single
> scatter-gather list to the API all in one go.
>   

You could have an API like:

try_to_map_or_bounce(list-of-phys-iovecs, buffer-to-bounce-to, callback, 
opaque);

That would be a nice addition for packet IO devices.  Better yet, it 
should be:

try_to_map_or_bounce(map-func, unmap-func, iofunc, opaque, 
list-of-phys-iovecs, buffer-to-bounce-to)

If you go back and look at my previous mails about packet helpers and 
stream helpers, that's just about the signature of my proposed packet 
helper.  Like I mentioned earlier, I definitely think we should have 
such a thing.

Regards,

Anthony Liguori

> Ian.
>
>
>