From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LQ4a4-0003tb-Bx for qemu-devel@nongnu.org; Thu, 22 Jan 2009 13:47:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LQ4a3-0003tC-EK for qemu-devel@nongnu.org; Thu, 22 Jan 2009 13:47:08 -0500 Received: from [199.232.76.173] (port=55246 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQ4a3-0003sy-9t for qemu-devel@nongnu.org; Thu, 22 Jan 2009 13:47:07 -0500 Received: from qw-out-1920.google.com ([74.125.92.148]:13854) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LQ4a2-0001M2-Vf for qemu-devel@nongnu.org; Thu, 22 Jan 2009 13:47:07 -0500 Received: by qw-out-1920.google.com with SMTP id 5so836231qwc.4 for ; Thu, 22 Jan 2009 10:47:06 -0800 (PST) Message-ID: <4978BF1B.9070400@codemonkey.ws> Date: Thu, 22 Jan 2009 12:46:51 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 1/5] Add target memory mapping API References: <1232308399-21679-1-git-send-email-avi@redhat.com> <1232308399-21679-2-git-send-email-avi@redhat.com> <49761B6A.2020806@codemonkey.ws> <18807.22215.857033.533504@mariner.uk.xensource.com> <49777949.2000602@codemonkey.ws> <18808.25646.904302.912481@mariner.uk.xensource.com> In-Reply-To: <18808.25646.904302.912481@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 Cc: Avi Kivity Ian Jackson wrote: > Anthony Liguori writes ("Re: [Qemu-devel] Re: [PATCH 1/5] Add target memory mapping API"): > > >>> The second criticism is a matter of taste, perhaps, and the third can >>> be addressed later: >>> >>> * The mixed call/callback API: [...] >>> >>> Callbacks are increasingly dominating the innards of qemu for good >>> reasons. I think I have explained how a callback style can provide >>> the necessary functionality. >>> >> I understand the point you make here and I think we'll end up having a >> callback API. But for reasons I've already mentioned, I don't think it >> makes sense for it to be the core API since it introduces very difficult >> to eliminate deadlocks. >> > > I think my most recently sketched-out proposal (where the caller > passes a DMA sg list to the mapping request function) doesn't have > these deadlocks ? > But what do you do with a DMA request that cannot possibly be bounced but that can be split? In other words, a DMA request to 1G of MMIO memory that is disk access. We can absolutely split that into multiple requests. > It seems to me that the way to avoid the deadlock is to allow the > caller to make their whole request at once rather than having two > callers both racing to grab resources. > In practice, you can't rely on being able to allocate enough memory in the host to complete a full request. This is only true for very special devices. You definitely need to support two distinct modes. Regards, Anthony Liguori > Regards, > Ian. > > >