From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBXdq-0004rr-PH for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:46:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBXdo-0004q0-7o for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:46:57 -0500 Received: from [199.232.76.173] (port=43910 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBXdn-0004pW-Gd for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:46:55 -0500 Received: from rn-out-0910.google.com ([64.233.170.190]:29577) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBXdn-00058R-4W for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:46:55 -0500 Received: by rn-out-0910.google.com with SMTP id 56so1715716rnw.8 for ; Sat, 13 Dec 2008 08:46:54 -0800 (PST) Message-ID: <4943E6F9.1050001@codemonkey.ws> Date: Sat, 13 Dec 2008 10:46:49 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4942B841.6010900@codemonkey.ws> <20081213143944.GD30537@random.random> In-Reply-To: <20081213143944.GD30537@random.random> 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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: chrisw@redhat.com, avi@redhat.com, Gerd Hoffmann , kvm@vger.kernel.org, qemu-devel@nongnu.org Andrea Arcangeli wrote: > On Fri, Dec 12, 2008 at 01:15:13PM -0600, Anthony Liguori wrote: > >> void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t size, int >> is_write); >> > > Just a side note (doesn't mean I agree with the above), it doesn't > make sense to use an ram_addr_t size when you return a 32bit address > on 32bit qemu build. > size_t is completely wrong for 64-bit targets on 32-bit hosts. ram_addr_t is the type we use for guest ram size. It's 64-bit all of the time simply because it's easier to do that and we decided that the little bit of wasted space/computations were not a problem. Regards, Anthony Liguori