From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S77AY-0001MY-3t for qemu-devel@nongnu.org; Mon, 12 Mar 2012 11:28:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S77AV-0007wB-TL for qemu-devel@nongnu.org; Mon, 12 Mar 2012 11:28:17 -0400 Received: from smtp111.dfw.emailsrvr.com ([67.192.241.111]:35274) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S77AV-0007vo-N7 for qemu-devel@nongnu.org; Mon, 12 Mar 2012 11:28:15 -0400 Message-ID: <4F5E1628.8080200@calxeda.com> Date: Mon, 12 Mar 2012 10:28:40 -0500 From: Mark Langsdorf 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> <4F5B6069.404@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 , Stefan Weil , "qemu-devel@nongnu.org" , Markus Armbruster , Erik Blake , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , David Gibson On 03/10/2012 09:27 AM, Peter Maydell wrote: > On 10 March 2012 14:08, Andreas F=C3=A4rber wrote: >> Am 10.03.2012 14:51, schrieb Peter Maydell: >>> "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. >=20 > I don't understand this remark. Nothing about the above explanation > is ARM-centric -- it's just pointing out that the guest and the > host are two separate things and maximum widths of size and > pointer types aren't necessarily the same. Assuming they were the > same would be an x86-64-ism :-) >> >> 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 wan= ts >> to pass a possibly stupid value unchecked to the common API. >=20 > Where the ARM specific code has particular restrictions then > I'm happy to have the ARM specific code either relax those, or > do explicit checks so we can fail cleanly or whatever. >=20 > Putting a "restrict to INT_MAX" in the highbank code is definitely > wrong (not least because passing values to load_image_targphys isn't > the only thing we use that field in arm_boot_info for!) > The ARM boot code needs updating because it shouldn't be > using 'int' for arm_boot_info.ram_size, and using target_phys_addr_t > the same as we do for initrd_size is the obvious thing. I have no > particular objection to having some new target_phys_size_t or whatever, > and I could be persuaded that we should follow the memory API in > using uint64_t for sizes, but it needs to be a type that either follows > guest phys addr restrictions or a fixed-width type which we have decree= d > is always large enough, not a type which varies based on host propertie= s. I'm reluctant to continue this thread, but I feel obliged to ask: what types of changes should I make to allow the highbank model to put with more than 2GB of emulated DRAM? I've fired off 3 versions of a patch that answers that question, some of which I've liked more than others. I'm willing to do a reasonable amount of refactoring the general QEMU image loading code, but I don't want to do that until I have a sense that the maintainers agree on the general solution and that I'm working toward their understand. Thanks for thinking this over. --Mark Langsdorf Calxeda, Inc.