From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39605) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz0aw-0005Uz-HK for qemu-devel@nongnu.org; Tue, 25 Oct 2016 08:12:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz0as-0002Qd-H8 for qemu-devel@nongnu.org; Tue, 25 Oct 2016 08:12:42 -0400 Received: from mail-ua0-x234.google.com ([2607:f8b0:400c:c08::234]:40271) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bz0as-0002QQ-Cl for qemu-devel@nongnu.org; Tue, 25 Oct 2016 08:12:38 -0400 Received: by mail-ua0-x234.google.com with SMTP id u14so12253508uau.7 for ; Tue, 25 Oct 2016 05:12:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20161025093711.17407-1-jcd@tribudubois.net> References: <20161025093711.17407-1-jcd@tribudubois.net> From: Peter Maydell Date: Tue, 25 Oct 2016 13:12:17 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH] Versatile memory should not exceed 256MB. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jean-Christophe Dubois Cc: qemu-arm , QEMU Developers On 25 October 2016 at 10:37, Jean-Christophe Dubois wrote: > For now Qemu accpet a memory size greater than 256 MB but it would > crash afterward. > > Versatile devices are starting at 256 MB bondary. > > Signed-off-by: Jean-Christophe Dubois > --- > hw/arm/versatilepb.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/hw/arm/versatilepb.c b/hw/arm/versatilepb.c > index 8ae5392..7f11651 100644 > --- a/hw/arm/versatilepb.c > +++ b/hw/arm/versatilepb.c > @@ -198,6 +198,14 @@ static void versatile_init(MachineState *machine, int board_id) > int done_smc = 0; > DriveInfo *dinfo; > > + if (machine->ram_size > 0x10000000) { > + /* devices are starting at address 0x10000000, > + * Memory cannot overlap with devices. > + */ > + fprintf(stderr, "Memory size cannot exceed 256MB\n"); > + exit(1); > + } > + > if (!machine->cpu_model) { > machine->cpu_model = "arm926"; > } > -- Ah, this is a long-standing bug. (I think I first tried to fix it five years or so back but that ran aground on people not liking a general approach where the MachineState indicated the maximum limit for the board.) In any case we seem to have ended up with each board model doing by-hand checks on the RAM size, so this is better than doing nothing. I've applied this to target-arm.next, but I've switched it to use error_report() rather than fprintf(). I also took the liberty of tidying up the commit message and comment text a bit. thanks -- PMM