From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYPLG-0001VB-Sh for qemu-devel@nongnu.org; Sat, 26 May 2012 18:20:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SYPLF-0004ot-67 for qemu-devel@nongnu.org; Sat, 26 May 2012 18:20:10 -0400 Received: from mo-p00-ob.rzone.de ([81.169.146.162]:12898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYPLE-0004oH-Vz for qemu-devel@nongnu.org; Sat, 26 May 2012 18:20:09 -0400 From: Kevin Wolf Date: Sun, 27 May 2012 00:17:34 +0200 References: <4F70C0E4.9000700@codemonkey.ws> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201205270017.34477@kevin-wolf.de> Subject: Re: [Qemu-devel] [PATCH] fix multiboot loading if load_end_addr == 0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Scott Moser , Anthony Liguori Am Montag, 26. M=E4rz 2012 21:27:00 schrieb Scott Moser: > The previous multiboot load code did not treat the case where > load_end_addr was 0 specially. The multiboot specification says the > following: > * load_end_addr > Contains the physical address of the end of the data segment. > (load_end_addr - load_addr) specifies how much data to load. This > implies that the text and data segments must be consecutive in the > OS image; this is true for existing a.out executable formats. If > this field is zero, the boot loader assumes that the text and data > segments occupy the whole OS image file. > > Signed-off-by: Scott Moser > > diff --git a/hw/multiboot.c b/hw/multiboot.c > index b4484a3..b1e04c5 100644 > --- a/hw/multiboot.c > +++ b/hw/multiboot.c > @@ -202,10 +202,16 @@ int load_multiboot(void *fw_cfg, > uint32_t mh_bss_end_addr =3D ldl_p(header+i+24); > mh_load_addr =3D ldl_p(header+i+16); > uint32_t mb_kernel_text_offset =3D i - (mh_header_addr - > mh_load_addr); - uint32_t mb_load_size =3D mh_load_end_addr - > mh_load_addr; > - > + uint32_t mb_load_size =3D 0; > mh_entry_addr =3D ldl_p(header+i+28); > - mb_kernel_size =3D mh_bss_end_addr - mh_load_addr; > + > + if (mh_load_end_addr) { > + mb_kernel_size =3D mh_bss_end_addr - mh_load_addr; > + mb_load_size =3D mh_load_end_addr - mh_load_addr; > + } else { > + mb_kernel_size =3D kernel_file_size - mb_kernel_text_offset; > + mb_load_size =3D mb_kernel_size; > + } > > /* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_VBE. > uint32_t mh_mode_type =3D ldl_p(header+i+32); Anthony, what happened with this patch? Can we still get it into 1.1? Kevin