From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55919)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <prvs=77085ab13=anthony.perard@citrix.com>)
	id 1a3p7u-0003SB-8R
	for qemu-devel@nongnu.org; Tue, 01 Dec 2015 12:54:10 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <prvs=77085ab13=anthony.perard@citrix.com>)
	id 1a3p7q-0003HR-90
	for qemu-devel@nongnu.org; Tue, 01 Dec 2015 12:54:06 -0500
Received: from smtp.citrix.com ([66.165.176.89]:41022)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <prvs=77085ab13=anthony.perard@citrix.com>)
	id 1a3p7q-0003HJ-2L
	for qemu-devel@nongnu.org; Tue, 01 Dec 2015 12:54:02 -0500
Date: Tue, 1 Dec 2015 17:53:57 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20151201175357.GC1788@perard.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Subject: [Qemu-devel] Regression: Xen guest with 5G of RAM on 32bit fail to
	boot
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: QEMU-devel <qemu-devel@nongnu.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Xen Devel <xen-devel@lists.xen.org>, "Dr. David Alan Gilbert" <dgilbert@redhat.com>, Juan Quintela <quintela@redhat.com>

Hi,

Under Xen, a guest with 5G of RAM, with a 32bit binary QEMU (well, with a
32bit dom0) does not boot anymore. QEMU abort() with "Bad ram offset efffd000".

This issue first appear in 4ed023ce2a39ab5812d33cf4d819def168965a7f (Round
up RAMBlock sizes to host page sizes).

The problem is in qemu_ram_alloc_internal() where 'size' and 'maxsize' are
now been truncate to 32bit, due to 'qemu_host_page_size' been an uintptr_t
in the HOST_PAGE_ALIGN macro.

ram_add_t is uint64_t when compiled with --enable-xen.

Regards,

-- 
Anthony PERARD