From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37742) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFka9-0006qo-7i for qemu-devel@nongnu.org; Mon, 17 Oct 2011 06:38:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFka7-00027t-Vz for qemu-devel@nongnu.org; Mon, 17 Oct 2011 06:38:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFka7-00027m-N6 for qemu-devel@nongnu.org; Mon, 17 Oct 2011 06:38:07 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9HAc6Me019875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Oct 2011 06:38:07 -0400 Message-ID: <4E9C058C.6060307@redhat.com> Date: Mon, 17 Oct 2011 12:38:04 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1318764264-22745-1-git-send-email-avi@redhat.com> <1318778947-1612-1-git-send-email-avi@redhat.com> <20111017053348.GC30114@truffala.fritz.box> In-Reply-To: <20111017053348.GC30114@truffala.fritz.box> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC128 3/2] Adjust system and pci address spaces to full 64-bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 10/17/2011 07:33 AM, David Gibson wrote: > On Sun, Oct 16, 2011 at 05:29:07PM +0200, Avi Kivity wrote: > > Now that the memory API supports full 64-bit buses, adjust the relevant > > callers to take advantage of it. > > Note that this doesn't, strictly speaking doesn't give you full 64-bit > coverage, since the range covered is 2^64-1 bytes rather than 2^64 > bytes. Cases where that will matter would be very rare, of course. > An undocumented and indeed unmentioned feature of patch 2 is that UINT64_MAX sizes are expanded to UINT64_MAX+1. I did that to avoid introducing memory_region_init_128() (or perhaps memory_region_init_2_64() that doesn't take a size argument). That removes the ability to create container regions that span exactly UINT64_MAX bytes. It is strange in a patchset that tries to makes things more regular, I admit. -- error compiling committee.c: too many arguments to function