From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLEis-00049B-DB for qemu-devel@nongnu.org; Tue, 01 Nov 2011 09:49:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLEio-0004IN-3O for qemu-devel@nongnu.org; Tue, 01 Nov 2011 09:49:50 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45578 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLEin-0004IF-S6 for qemu-devel@nongnu.org; Tue, 01 Nov 2011 09:49:46 -0400 Message-ID: <4EAFF8A9.8050302@suse.de> Date: Tue, 01 Nov 2011 14:48:25 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1319983368-21801-1-git-send-email-avi@redhat.com> <4EAEC75B.6020006@codemonkey.ws> <20111101005401.GC6895@truffala.fritz.box> <4EAFB13C.5090104@redhat.com> <4EAFED2E.8000009@codemonkey.ws> In-Reply-To: <4EAFED2E.8000009@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , Avi Kivity , qemu-devel@nongnu.org Am 01.11.2011 13:59, schrieb Anthony Liguori: > On 11/01/2011 03:43 AM, Avi Kivity wrote: >> On 11/01/2011 02:54 AM, David Gibson wrote: >>> On Mon, Oct 31, 2011 at 11:05:47AM -0500, Anthony Liguori wrote: >>>> On 10/30/2011 09:02 AM, Avi Kivity wrote: >>>>> This somewhat controversial patchset converts internal arithmetic >>>>> in the >>>>> memory API to 128 bits. >>>> >>>> Given the level of controversy, what do you think about deferring >>>> this to 1.1? >>> >>> If it's deferred then one of my rearrangements for the arithmetic mus= t >>> go in instead. These patches fix real bugs, that bite us on pseries. >>> It's not the only way to fix those bugs, and probably not even my >>> personally preferred way to fix them, but they need to be fixed >>> _somehow_ for 1.0. >> >> Yes, plus if one of them is exploitable, then it's certainly a must >> for 1.0. >=20 > Since it's just internal, I'll just pull this series and if we want to > change it post 1.0, we can. FWIW I must say I don't like where this is heading... iiuc just because of a zero-or-full-64-bits issue with start+end we're doubling the internal storage format for all memory ranges. If having the size unsigned would eliminate the overflow issue at hand, can't we move the signedness to some flag field instead? I don't see a problem with using macros/inlines, just with the seemingly unnecessary 128-bitness. In particular I'm thinking of ARM. Since this seems to be addressing an overflow bug in ppc64, the hard-freeze date shouldn't make us rush this IMO. 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