From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LBbmN-0005XN-Mp
	for qemu-devel@nongnu.org; Sat, 13 Dec 2008 16:12:03 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LBbmM-0005X3-9w
	for qemu-devel@nongnu.org; Sat, 13 Dec 2008 16:12:03 -0500
Received: from [199.232.76.173] (port=59129 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LBbmM-0005Wz-3V
	for qemu-devel@nongnu.org; Sat, 13 Dec 2008 16:12:02 -0500
Received: from an-out-0708.google.com ([209.85.132.251]:52998)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1LBbmL-00086B-Tx
	for qemu-devel@nongnu.org; Sat, 13 Dec 2008 16:12:02 -0500
Received: by an-out-0708.google.com with SMTP id c38so998187ana.37
	for <qemu-devel@nongnu.org>; Sat, 13 Dec 2008 13:12:01 -0800 (PST)
Message-ID: <4944251D.8080109@codemonkey.ws>
Date: Sat, 13 Dec 2008 15:11:57 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <cc5d812eb9369a7ad2ef.1229105804@duo.random>
	<4942B841.6010900@codemonkey.ws>
	<20081213143944.GD30537@random.random>
	<4943E6F9.1050001@codemonkey.ws>
	<20081213165306.GE30537@random.random>
In-Reply-To: <20081213165306.GE30537@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: <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: Andrea Arcangeli <aarcange@redhat.com>
Cc: chrisw@redhat.com, avi@redhat.com, Gerd Hoffmann <kraxel@redhat.com>, kvm@vger.kernel.org, qemu-devel@nongnu.org

Andrea Arcangeli wrote:
> On Sat, Dec 13, 2008 at 10:46:49AM -0600, Anthony Liguori wrote:
>   
> 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.
>   

If you take a size_t, then all callers have to validate that the size 
they're passing in (which may originate from the guest), is not going to 
cause an overflow.  You will naturally validate this in the map() 
function because you cannot map something that is greater than can fit 
in a void *.  All callers have to handle the case where return is NULL 
from map() which means that you can fold this error checking into map() 
without the callers having to even think of it.

Regards,

Anthony Liguori