|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH 2/5] Add map client retry notification |
Date: | Thu, 22 Jan 2009 12:51:29 -0600 |
User-agent: | Thunderbird 2.0.0.19 (X11/20090105) |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |