From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Date: Sat, 13 Dec 2008 17:53:07 +0100 Message-ID: <20081213165306.GE30537@random.random> References: <4942B841.6010900@codemonkey.ws> <20081213143944.GD30537@random.random> <4943E6F9.1050001@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Gerd Hoffmann , qemu-devel@nongnu.org, kvm@vger.kernel.org, avi@redhat.com, chrisw@redhat.com To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:58325 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750820AbYLMQxO (ORCPT ); Sat, 13 Dec 2008 11:53:14 -0500 Content-Disposition: inline In-Reply-To: <4943E6F9.1050001@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Sat, Dec 13, 2008 at 10:46:49AM -0600, Anthony Liguori wrote: > 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. Not sure why you think I'm suggesting you to use size_t. I'm just trying to tell you that if you insist in this 64bit-guest-on-32bit-host-is-dead-and-obsolete-to-support (i.e. if you pass a ram_addr_t size to cpu_physical_memory_map) you've at least to return ram_addr_t too). 'void *' is like size_t so the above API getting ram_addr_t length and returning 'void *', can't possibly be sane. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBXjv-0001R5-TD for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:53:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBXju-0001Ok-HX for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:53:15 -0500 Received: from [199.232.76.173] (port=42898 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBXju-0001O6-0C for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:53:14 -0500 Received: from mx2.redhat.com ([66.187.237.31]:40810) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBXjt-0005se-GL for qemu-devel@nongnu.org; Sat, 13 Dec 2008 11:53:13 -0500 Date: Sat, 13 Dec 2008 17:53:07 +0100 From: Andrea Arcangeli Message-ID: <20081213165306.GE30537@random.random> References: <4942B841.6010900@codemonkey.ws> <20081213143944.GD30537@random.random> <4943E6F9.1050001@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4943E6F9.1050001@codemonkey.ws> 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: Anthony Liguori Cc: chrisw@redhat.com, avi@redhat.com, Gerd Hoffmann , kvm@vger.kernel.org, qemu-devel@nongnu.org On Sat, Dec 13, 2008 at 10:46:49AM -0600, Anthony Liguori wrote: > 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. Not sure why you think I'm suggesting you to use size_t. I'm just trying to tell you that if you insist in this 64bit-guest-on-32bit-host-is-dead-and-obsolete-to-support (i.e. if you pass a ram_addr_t size to cpu_physical_memory_map) you've at least to return ram_addr_t too). 'void *' is like size_t so the above API getting ram_addr_t length and returning 'void *', can't possibly be sane.