From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] fix multiboot loading if load_end_addr == 0 Date: Sat, 17 Mar 2012 14:27:55 +0100 Message-ID: <4F64915B.6060104@web.de> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF126C1FC8C3A10565FC0EDD8" Cc: kvm@vger.kernel.org To: Scott Moser Return-path: Received: from fmmailgate04.web.de ([217.72.192.242]:45191 "EHLO fmmailgate04.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030858Ab2CQN2D (ORCPT ); Sat, 17 Mar 2012 09:28:03 -0400 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate04.web.de (Postfix) with ESMTP id 8F37F73ED723 for ; Sat, 17 Mar 2012 14:28:01 +0100 (CET) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF126C1FC8C3A10565FC0EDD8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-03-17 05:08, Scott Moser wrote: > The previous 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. >=20 > This was raised initially as launchpad bug > https://bugs.launchpad.net/qemu/+bug/957622 >=20 > 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_lo= ad_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_offse= t; > + mb_load_size =3D mb_kernel_size; > + } >=20 > /* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_VBE. > uint32_t mh_mode_type =3D ldl_p(header+i+32); Almost everything should go to upstream directly these days, including this fix. Jan --------------enigF126C1FC8C3A10565FC0EDD8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9kkV8ACgkQitSsb3rl5xQzfgCgm65rhtG2hIsdVfsi7ulrsoaO JLwAnii+dTycRXS/57YjFyhpOhm8TUC2 =XX6b -----END PGP SIGNATURE----- --------------enigF126C1FC8C3A10565FC0EDD8--