From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPisl-0003mG-LW for qemu-devel@nongnu.org; Wed, 21 Jan 2009 14:36:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPisk-0003lU-RX for qemu-devel@nongnu.org; Wed, 21 Jan 2009 14:36:59 -0500 Received: from [199.232.76.173] (port=41918 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPisk-0003ky-II for qemu-devel@nongnu.org; Wed, 21 Jan 2009 14:36:58 -0500 Received: from qw-out-1920.google.com ([74.125.92.150]:19284) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPisk-00040C-2p for qemu-devel@nongnu.org; Wed, 21 Jan 2009 14:36:58 -0500 Received: by qw-out-1920.google.com with SMTP id 5so725681qwc.4 for ; Wed, 21 Jan 2009 11:36:55 -0800 (PST) Message-ID: <49777949.2000602@codemonkey.ws> Date: Wed, 21 Jan 2009 13:36:41 -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> In-Reply-To: <18807.22215.857033.533504@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 ("[Qemu-devel] Re: [PATCH 1/5] Add target memory mapping API"): > >> I've gone though the thread again and I think this patch series is a >> pretty good start. I think the API can be refined a bit more down the >> road to better support Xen but I think this is a good start. >> > > I'm afraid I disagree. > That's why I sent a note first instead of just committing :-) >> Does anyone have major blockers with this API? If not, I'd like to >> commit these patches. The consumers of it should be small provided that >> we make sure to write helpers for the various types of IO pipelines. >> > > I have three criticisms, the first of which is in my view a major > blocker: > Okay, then let's ignore the last two for now. A DMA API is really important for performance and I'd like to get something in the tree we can start working with. > * The unmap call should take a transfer length, for the reasons > I have explained. > I have a hard time disagree that it should take a transfer length, if for nothing else, to use to update the right amount of the dirty bitmap. Avi, do you object to having unmap take a transfer length? FWIW, I don't think we need to support RMW operations right now, but I think the transfer length is still required since you may get a partial IO result. It may not be an important issue of correctness but it's still an issue of correctness. > I think it is important that the API permits implementations where > the memory cannot be just mapped. At the moment the APIs used by > qemu device emulations do not assume that they can access RAM > willy-nilly; they are all expected to go through > cpu_physical_memory_rw. I think it is important to preserve this > for the future flexibility of the qemu codebase. > map() can, and will, fail under certain conditions and the code has to accommodate that. > I'm trying to preserve an important and useful property of the > internal qemu API. My suggestion will mean the device emulation > parts of qemu continue to be reasonably easily useable separately > from the rest of qemu, and possibly very separately from any > emulation of CPU or memory. The benefit is difficult to evaluate > exactly but the cost is very small. > Are you arguing for "callback" based mapping? The vast majority of devices will end up using a callback based approach so I'm not sure what you're unhappy about. > The second criticism is a matter of taste, perhaps, and the third can > be addressed later: > > * The mixed call/callback API: DMAs which can be mappped immediately > are treated as synchronous calls; ones which can't involve a > separate callback. > > This is no different semantically from a pure-callback API. > However, it makes life more clumsy for the caller - the caller now > needs two code paths: one for immediate success, and one for > deferred allocation. > > 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. > * The documentation, in the form of comments describing the > semantics of and restrictions on the use of the DMA mapping, > is inadequate. > It is. Avi has promised to fix that :-) Regards, Anthony Liguori > Ian. > > >