From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LBk8M-0005el-KQ
	for qemu-devel@nongnu.org; Sun, 14 Dec 2008 01:07:18 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LBk8L-0005e8-6G
	for qemu-devel@nongnu.org; Sun, 14 Dec 2008 01:07:17 -0500
Received: from [199.232.76.173] (port=36483 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LBk8L-0005e2-00
	for qemu-devel@nongnu.org; Sun, 14 Dec 2008 01:07:17 -0500
Received: from mx2.redhat.com ([66.187.237.31]:41851)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1LBk8K-0007zK-Ce
	for qemu-devel@nongnu.org; Sun, 14 Dec 2008 01:07:16 -0500
Message-ID: <4944A28D.50302@redhat.com>
Date: Sun, 14 Dec 2008 08:07:09 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <cc5d812eb9369a7ad2ef.1229105804@duo.random>
	<4942B841.6010900@codemonkey.ws> <49443B6B.3030907@codemonkey.ws>
In-Reply-To: <49443B6B.3030907@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Andrea Arcangeli <aarcange@redhat.com>, chrisw@redhat.com, Gerd Hoffmann <kraxel@redhat.com>, kvm@vger.kernel.org, qemu-devel@nongnu.org

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.