From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vi5C3-0007rp-DI for qemu-devel@nongnu.org; Sun, 17 Nov 2013 11:27:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vi5Bw-0000LE-LS for qemu-devel@nongnu.org; Sun, 17 Nov 2013 11:27:27 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:53685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vi5Bw-0000L3-7V for qemu-devel@nongnu.org; Sun, 17 Nov 2013 11:27:20 -0500 Received: by mail-lb0-f169.google.com with SMTP id x18so3014680lbi.28 for ; Sun, 17 Nov 2013 08:27:18 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1384704624-3860-1-git-send-email-chenq009@gmail.com> References: <1384704624-3860-1-git-send-email-chenq009@gmail.com> From: Peter Maydell Date: Sun, 17 Nov 2013 16:26:57 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH] fix initrd load failed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ChenQun Cc: QEMU Developers , "kvmarm@lists.cs.columbia.edu" On 17 November 2013 16:10, ChenQun wrote: > Here's a bug, some examples are as follows: > 1.Assuming Guest's filesystem size 6M. > 2.For vexpress_a15, the loader_start = 2048M. > If we set guest ram_size range from 2048M+128M to 2048M+128M+6M, > then the initrd load failed. > 3.For mach-virt, the loader_start = 128M. > If we set guest ram_size range from 256M to 256M+6M, then it is > failed too. > > So,it is a bug for load initrd max mem calculation. > It should be (ram_size + loader_start - initrd_start). Yes, this is definitely a bug. The set of addresses/sizes we pass to the loader is a bit of a mess, though -- we kind of implicitly assume that "loader_start" means "bottom of RAM", and that all the ram is in one chunk. However for example realview-pbx-a9 sets loader_start to 0 when the size of that bit of RAM may be less than the total ram_size. The device tree editing code also assumes a single contiguous block of RAM... thanks -- PMM