From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPiE2-0002yJ-Vk for qemu-devel@nongnu.org; Wed, 21 Jan 2009 13:54:55 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPiDx-0002p5-Uh for qemu-devel@nongnu.org; Wed, 21 Jan 2009 13:54:51 -0500 Received: from [199.232.76.173] (port=57343 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPiDv-0002oJ-LM for qemu-devel@nongnu.org; Wed, 21 Jan 2009 13:54:47 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:45759) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPiDv-00083k-1d for qemu-devel@nongnu.org; Wed, 21 Jan 2009 13:54:47 -0500 Received: by qyk13 with SMTP id 13so5816706qyk.10 for ; Wed, 21 Jan 2009 10:54:45 -0800 (PST) Date: Wed, 21 Jan 2009 13:56:29 -0500 From: Mike Day Message-ID: <20090121185629.GA326@silverwood.ncultra.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18807.22215.857033.533504@mariner.uk.xensource.com> Subject: [Qemu-devel] Re: Add target memory mapping API Reply-To: ncmike@ncultra.org, 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 On 21/01/09 17:09 +0000, 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. > > > 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: > > * The unmap call should take a transfer length, for the reasons > I have explained. > > This is absolutely critical for correctness if bounce buffers are > used. > > 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. cpu_physical_memory_rw will still be available and used by most devices even with this proposed API, right? Certain devices will be able to now use the new API. > Note that Xen is not such an implementation, although in the Xen > case the additional performance of mapping is not so important so > we might not choose to implement the mapping right away. Obviously > it would be much easier for us just to implement this mapping than > to argue at length on this list. It's not hard for Xen. So I'm > not trying to special-case Xen here. You shouldn't read my > criticisms as some kind of Xen fanatic trying to defend some crazy > Xen behaviour. > > 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. > > Of my criticisms, I think this is by far the most important. It > relates to the correctness of the API and in my view it is essential > that this be properly addressed. > > Avi will say again (as if repetition made things true) that `bounce > buffers are never used' but of course they will be sometimes. If they > were never used his patch wouldn't need to have that code in them. > It's true that they will be _rarely_ used but a lack of correctness in > a rare case is not acceptable either. I think a DMA into a device MMIO range is a special case. Mike -- Mike Day http://www.ncultra.org AIM: ncmikeday | Yahoo IM: ultra.runner PGP key: http://www.ncultra.org/ncmike/pubkey.asc