From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LQ4ee-0006CA-Bn for qemu-devel@nongnu.org; Thu, 22 Jan 2009 13:51:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LQ4ed-0006Ba-5X for qemu-devel@nongnu.org; Thu, 22 Jan 2009 13:51:51 -0500 Received: from [199.232.76.173] (port=48078 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQ4ec-0006BS-UU for qemu-devel@nongnu.org; Thu, 22 Jan 2009 13:51:50 -0500 Received: from qw-out-1920.google.com ([74.125.92.147]:14795) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LQ4ec-0001q5-JD for qemu-devel@nongnu.org; Thu, 22 Jan 2009 13:51:50 -0500 Received: by qw-out-1920.google.com with SMTP id 5so836753qwc.4 for ; Thu, 22 Jan 2009 10:51:50 -0800 (PST) Message-ID: <4978C031.5080306@codemonkey.ws> Date: Thu, 22 Jan 2009 12:51:29 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/5] Add map client retry notification References: <1232620587-11625-1-git-send-email-avi@redhat.com> <1232620587-11625-3-git-send-email-avi@redhat.com> <18808.26322.736884.264358@mariner.uk.xensource.com> In-Reply-To: <18808.26322.736884.264358@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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() succeeds > map() 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. > > >