From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Date: Sun, 14 Dec 2008 08:07:09 +0200 Message-ID: <4944A28D.50302@redhat.com> References: <4942B841.6010900@codemonkey.ws> <49443B6B.3030907@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrea Arcangeli , Gerd Hoffmann , qemu-devel@nongnu.org, kvm@vger.kernel.org, chrisw@redhat.com To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:35830 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750774AbYLNGHR (ORCPT ); Sun, 14 Dec 2008 01:07:17 -0500 In-Reply-To: <49443B6B.3030907@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > Anthony Liguori wrote: >> >> This could correspond to a: >> >> void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t >> size, int is_write); >> >> void cpu_physical_memory_unmap(target_physical_addr_t addr, >> ram_addr_t size, void *mapping, int is_dirty); > > A really nice touch here, and note this is optional and can be a > follow up series later, would be to use the mapping itself to encode > the physical address and size so the signatures were: > > void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t > size, int flags); > void cpu_physical_memory_unmap(void *mapping); > > flags could be PHYS_MAP_READ and/or PHYS_MAP_WRITE. > > In unmap, you could check to see if the address is in phys_ram_base > ... phys_ram_size. If so, you can get the physical address. > > If you maintained a list of mappings, you could then search the list > of mappings based on the physical address and check the flags to see > if a flush was required. That will come back and bite us when we implement memory slots (for memory hotplug, etc.). You want here to return two values - a pointer for the caller's use, and some information for unmap's use. The best thing to do is return two values instead of having unmap() try to figure out the things that map() has already calculated. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.