From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50761 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OeyVV-0005d2-Ox for qemu-devel@nongnu.org; Fri, 30 Jul 2010 18:56:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OeyVU-0003Gc-72 for qemu-devel@nongnu.org; Fri, 30 Jul 2010 18:56:49 -0400 Received: from mail-ew0-f45.google.com ([209.85.215.45]:40668) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OeyVU-0003GL-2W for qemu-devel@nongnu.org; Fri, 30 Jul 2010 18:56:48 -0400 Received: by ewy5 with SMTP id 5so1019349ewy.4 for ; Fri, 30 Jul 2010 15:56:46 -0700 (PDT) Date: Sat, 31 Jul 2010 00:56:42 +0200 From: "Edgar E. Iglesias" Subject: Re: [Qemu-devel] [PATCH] loader: pad kernel size when loaded from a uImage Message-ID: <20100730225641.GA20899@laped.lan> References: <1280454504-31224-1-git-send-email-hollis@penguinppc.org> <1280454504-31224-2-git-send-email-hollis@penguinppc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1280454504-31224-2-git-send-email-hollis@penguinppc.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hollis Blanchard Cc: qemu-devel@nongnu.org, kvm-ppc@vger.kernel.org On Thu, Jul 29, 2010 at 06:48:24PM -0700, Hollis Blanchard wrote: > The kernel's BSS size is lost by mkimage, which only considers file > size. As a result, loading other blobs (e.g. device tree, initrd) > immediately after the kernel location can result in them being zeroed by > the kernel's BSS initialization code. > > Signed-off-by: Hollis Blanchard > --- > hw/loader.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/hw/loader.c b/hw/loader.c > index 79a6f95..35bc25a 100644 > --- a/hw/loader.c > +++ b/hw/loader.c > @@ -507,6 +507,13 @@ int load_uimage(const char *filename, target_phys_addr_t *ep, > > ret = hdr->ih_size; > > + /* The kernel's BSS size is lost by mkimage, which only considers file > + * size. We don't know how big it is, but we do know we can't place > + * anything immediately after the kernel. The padding seems like it should > + * be proportional to overall file size, but we also make sure it's at > + * least 4-byte aligned. */ > + ret += (hdr->ih_size / 16) & ~0x3; Maybe it's only me, but it feels a bit akward to push down this kind of knowledge down the abstraction layers. Does it work for you to have your caller of load_uimage apply whatever resizing magic needed for your kernel and arch? Cheers