From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsEMJ-0007no-6a for qemu-devel@nongnu.org; Tue, 31 Jan 2012 09:07:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsEMF-0004Ea-Fa for qemu-devel@nongnu.org; Tue, 31 Jan 2012 09:06:55 -0500 Message-ID: <4F27F63E.9050307@redhat.com> Date: Tue, 31 Jan 2012 15:10:06 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <87mx9ezir8.fsf@industria.weinholt.se> In-Reply-To: <87mx9ezir8.fsf@industria.weinholt.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] multiboot: mh_load_end_addr and mh_bss_end_addr may be zero List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?R8O2cmFuIFdlaW5ob2x0?= Cc: =?UTF-8?B?UmVuw6kgUmViZQ==?= , qemu-stable@nongnu.org, "Justin M. Forbes" , qemu-devel@nongnu.org, Alexander Graf Am 23.01.2012 13:49, schrieb G=C3=B6ran Weinholt: > There are two special cases in the address fields of the multiboot > format. If mh_load_end_addr is zero then the whole image file should > be loaded and if mh_bss_end_addr is zero then there is no bss segment. > With this change it is again possible to boot kernels where these > fields are zero. >=20 > Signed-off-by: G=C3=B6ran Weinholt > Tested-by: Alexander Graf > --- > hw/multiboot.c | 15 ++++++++++++++- > 1 files changed, 14 insertions(+), 1 deletions(-) >=20 > diff --git a/hw/multiboot.c b/hw/multiboot.c > index b4484a3..db28328 100644 > --- a/hw/multiboot.c > +++ b/hw/multiboot.c > @@ -202,10 +202,23 @@ 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_lo= ad_addr); > - uint32_t mb_load_size =3D mh_load_end_addr - mh_load_addr; > + uint32_t mb_load_size; > + > + /* A load end address of zero indicates that the whole file > + * should be loaded. */ > + if (!mh_load_end_addr) { > + mh_load_end_addr =3D kernel_file_size + mh_load_addr; This is only right if the OS image starts at offset 0 in the image file. IIUC, in the general case it starts at byte i - (mh_header_addr - mh_load_addr), so you need to subtract this from kernel_file_size. Kevin