From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6MyV-0001mB-Ur for qemu-devel@nongnu.org; Sat, 10 Mar 2012 09:08:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6MyT-0000k3-UN for qemu-devel@nongnu.org; Sat, 10 Mar 2012 09:08:47 -0500 Received: from cantor2.suse.de ([195.135.220.15]:35009 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6MyT-0000jO-LD for qemu-devel@nongnu.org; Sat, 10 Mar 2012 09:08:45 -0500 Message-ID: <4F5B6069.404@suse.de> Date: Sat, 10 Mar 2012 15:08:41 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1331225951-31306-1-git-send-email-mark.langsdorf@calxeda.com> <4F5A0288.6090809@calxeda.com> <9A556F7F-2721-4D51-80D2-8B9571E4EC0F@suse.de> <4F5A06C8.7020903@calxeda.com> <88D21EA9-1000-48DB-9D7A-437622BE8745@suse.de> <4F5A1378.5040909@suse.de> <4F5A503D.2090304@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] use an unsigned long for the max_sz parameter in load_image_targphys List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Alexander Graf , Mark Langsdorf , Stefan Weil , "qemu-devel@nongnu.org" , Markus Armbruster , Erik Blake , David Gibson Am 10.03.2012 14:51, schrieb Peter Maydell: > On 9 March 2012 18:47, Andreas F=C3=A4rber wrote: >> Am 09.03.2012 18:11, schrieb Peter Maydell: >>> On 9 March 2012 14:28, Andreas F=C3=A4rber wrote: >>>> No, please. We're describing sizes, not addresses. target_phys_addr_= t >>>> thus is semantically wrong here. The RAM size is unsigned long IIRC = (it >>>> is limited by the host's available memory). If you subtract somethin= g >>>> from a size it remains a size. I had therefore suggested size_t befo= re. >>>> I expect sizeof(size_t) >=3D sizeof(unsigned long). >>> >>> We're discussing target sizes. size_t might be smaller than >>> target_phys_addr_t, so it's also semantically wrong. We don't >>> have a target_size_t, though, and I think "use an address >>> related type for an offset" is less bad than "use a host >>> sized type for a guest sized value". >> >> That is a moot point. There is no such thing as a "target size". >=20 > "Length of a block of memory on the guest" is what I meant. > What you need is "an integer type large enough to hold the > difference between two guest pointer values". The size of > that type should depend only on the guest config, not on the > host, so 'unsigned long', 'size_t', 'off_t' etc are all wrong. Your view is very ARM-centric. In the PowerPC domain for instance, we have a number of usages where we hardcode a size of, e.g., 1 MB. And Alex should know that. I don't want to use target_phys_addr_t for that and forcing an end address calculation, as suggested by Alex, would be possible but is not as convenient as the current API. Doing a size check as Mark has demonstrated in ARM code (one place!) seems much simpler to me than hurting all targets just because ARM wants to pass a possibly stupid value unchecked to the common API. Compare David's off_t patch from March 8th: We'll never get an image size larger than off_t's max. Using target_phys_addr_t, uint64_t or __int128_t for the max are all moot (academic) because we'll never get to their max if it's larger than off_t. Therefore I've been saying, the host's limit is the upper realistic limit for image_load_targphys(). ELF may be a different case to consider since it can be sparse. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg