From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S656g-0007yn-Bz for qemu-devel@nongnu.org; Fri, 09 Mar 2012 14:04:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S656a-000851-0O for qemu-devel@nongnu.org; Fri, 09 Mar 2012 14:04:01 -0500 Received: from cantor2.suse.de ([195.135.220.15]:51349 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S656Z-000844-Mq for qemu-devel@nongnu.org; Fri, 09 Mar 2012 14:03:55 -0500 Message-ID: <4F5A541A.8040203@suse.de> Date: Fri, 09 Mar 2012 20:03:54 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1331225951-31306-1-git-send-email-mark.langsdorf@calxeda.com> <1331308660-20787-1-git-send-email-mark.langsdorf@calxeda.com> <4F5A3267.70607@calxeda.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] arm highbank: force ramsize to INT_MAX when loading List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , Mark Langsdorf , "qemu-devel@nongnu.org" , "armbru@redhat.com" , "eblake@redhat.com" , "david@gibson.dropbear.id.au" Am 09.03.2012 19:22, schrieb Alexander Graf: >=20 > On 09.03.2012, at 17:40, Mark Langsdorf wrote: >=20 >> On 03/09/2012 10:13 AM, Peter Maydell wrote: >>> On 9 March 2012 15:57, Mark Langsdorf wr= ote: >>>> Since the ram_size field of arm_boot_info is only an int, don't set >>>> that field to more than INT_MAX. Signed vs unsigned comparison >>>> overruns are possible otherwise. >>> >>> Can't we just make arm_boot_info.ram_size a uint32_t (propagating thr= ough >>> signedness fixes as required) ? >>> >>> Actually it should probably be a target_phys_addr_t, thinking ahead >>> to adding LPAE support. >> >> It really should be a size_t, per the upthread discussion with Andreas >> Faerber. >=20 > No, Andreas is wrong. Host data types have nothing to do in target ram = fiddling code. The type you're searching for is "the size of physical add= ress space the guest can handle" and that's target_phys_addr_t. Period. That is exactly where we disagree: It's not "target ram fiddling code". It's the host loading binaries from disk to host RAM. The Memory API constructs for wiring it up in guest RAM are outside the scope of this discussion. If we can't load a 4 GB file into our host RAM, there's no point bloating our APIs with unreadable types as arguments such as "target_phys_addr_t max_size" just because a 64-bit guest on a 32-bit host has a larger virtual address space. It's not an address, so if we end up needing a special type it should certainly not be any ...addr_t type. Typedef target_phys_size_t if you see a need but keep our APIs clean please. Alex, you say you don't care about infrastructure, well this IS infrastructure and I care about its API and usability. :) Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg