From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LRVol-0003jO-Ms for qemu-devel@nongnu.org; Mon, 26 Jan 2009 13:04:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LRVok-0003ht-Ov for qemu-devel@nongnu.org; Mon, 26 Jan 2009 13:04:15 -0500 Received: from [199.232.76.173] (port=45524 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LRVok-0003hT-DF for qemu-devel@nongnu.org; Mon, 26 Jan 2009 13:04:14 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:63141) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LRVoj-0005zl-KB for qemu-devel@nongnu.org; Mon, 26 Jan 2009 13:04:13 -0500 Received: by qyk13 with SMTP id 13so9655276qyk.10 for ; Mon, 26 Jan 2009 10:04:12 -0800 (PST) Message-ID: <497DFB0D.7070008@codemonkey.ws> Date: Mon, 26 Jan 2009 12:03:57 -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> <4978BF1B.9070400@codemonkey.ws> <18813.43869.367796.341414@mariner.uk.xensource.com> In-Reply-To: <18813.43869.367796.341414@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: > Anthony Liguori writes ("Re: [Qemu-devel] Re: [PATCH 1/5] Add target memory mapping API"): > >> Ian Jackson wrote: >> >>> 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. >> > > You impose a maximum size for any DMA request; that is, a maximum size > that callers of the DMA API are allowed to request. Any larger > request is a bug. Callers who might want to try to map bigger blocks > need to be able to split. > > Alternatively you can have the API return an `amount mapped' on the > callback, but state that this number will always be at least > DMA_MAP_SG_GUARANTEE_MIN if at least that amount was requested. > For that to be useful for network traffic, it has to be at least 64k. If isn't at least 64k, then the NIC code must deal with two cases, one where it was able to map and one where it wasn't able to map. In the general case, we can't know ahead of time what the largest MIN is to make all devices happy. Regards, Anthony Liguori > Ian. > > >