From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58042) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLXtN-0004e7-Iv for qemu-devel@nongnu.org; Wed, 02 Nov 2011 06:17:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLXtL-0002Ey-U7 for qemu-devel@nongnu.org; Wed, 02 Nov 2011 06:17:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLXtL-0002Ea-CY for qemu-devel@nongnu.org; Wed, 02 Nov 2011 06:17:55 -0400 Message-ID: <4EB118CE.5080507@redhat.com> Date: Wed, 02 Nov 2011 12:17:50 +0200 From: Avi Kivity 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> <4EAFF8A9.8050302@suse.de> In-Reply-To: <4EAFF8A9.8050302@suse.de> 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: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Blue Swirl , qemu-devel@nongnu.org On 11/01/2011 03:48 PM, Andreas F=E4rber wrote: > >=20 > > Since it's just internal, I'll just pull this series and if we want t= o > > 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=20 It's not just that issue. > we're doubling the > internal storage format for all memory ranges.=20 It's not doubled, since the MemoryRegion structure has many other members. And anyway there are too few such structures to matter. On the other hand, when we get to rewrite the core we can eliminate the PageDesc array at 16 bytes per guest page, that is a really significant saving. > If having the size > unsigned would eliminate the overflow issue at hand, can't we move the > signedness to some flag field instead? You mean a 65-bit integer? > I don't see a problem with using macros/inlines, just with the seemingl= y > unnecessary 128-bitness. In particular I'm thinking of ARM. We could rename Int128 something like AddrArith and make it 64-bit for archs with 32-bit target_phys_addr_t. However I don't think there's much point. This code is executed very rarely, at initialization time and when the physical address map changes (like when mapping a BAR).=20 There's no point in optimizing it (and every point for making it robust). > Since this seems to be addressing an overflow bug in ppc64, the > hard-freeze date shouldn't make us rush this IMO. The bug it fixes is actually in code not yet merged. But I'm certain there are more lurking in there, we're taking guest supplied 64-bit values and using 64-bit arithmetic on them. It has to overflow. --=20 error compiling committee.c: too many arguments to function