From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [PATCH v16 7/9] x86: make Xen early boot code relocatable Date: Thu, 13 Apr 2017 14:43:22 -0500 Message-ID: <7194c400-7db1-2cd1-b969-deca1905606a@cardoe.com> References: <1487704799-21162-1-git-send-email-daniel.kiper@oracle.com> <1487704799-21162-8-git-send-email-daniel.kiper@oracle.com> <58E792D5020000780014E7D1@prv-mh.provo.novell.com> <20170413141125.GN16658@olila.local.net-space.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4958803180747191985==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cykeS-0003yV-Ai for xen-devel@lists.xenproject.org; Thu, 13 Apr 2017 19:43:32 +0000 Received: by mail-io0-f194.google.com with SMTP id x86so15107998ioe.3 for ; Thu, 13 Apr 2017 12:43:30 -0700 (PDT) In-Reply-To: <20170413141125.GN16658@olila.local.net-space.pl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Daniel Kiper , Jan Beulich Cc: Juergen Gross , sstabellini@kernel.org, andrew.cooper3@citrix.com, pgnet.dev@gmail.com, ning.sun@intel.com, julien.grall@arm.com, xen-devel@lists.xenproject.org, qiaowei.ren@intel.com, gang.wei@intel.com, fu.wei@linaro.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============4958803180747191985== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5ld2fOgIJouV3oluBWo2XUKdlTewlxSDm" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5ld2fOgIJouV3oluBWo2XUKdlTewlxSDm Content-Type: multipart/mixed; boundary="RLQFH7DUOqEhVl3HiUE6AfAfWrqnhlhQE"; protected-headers="v1" From: Doug Goldstein To: Daniel Kiper , Jan Beulich Cc: julien.grall@arm.com, andrew.cooper3@citrix.com, pgnet.dev@gmail.com, gang.wei@intel.com, ning.sun@intel.com, qiaowei.ren@intel.com, sstabellini@kernel.org, fu.wei@linaro.org, xen-devel@lists.xenproject.org, konrad.wilk@oracle.com, Juergen Gross Message-ID: <7194c400-7db1-2cd1-b969-deca1905606a@cardoe.com> Subject: Re: [PATCH v16 7/9] x86: make Xen early boot code relocatable References: <1487704799-21162-1-git-send-email-daniel.kiper@oracle.com> <1487704799-21162-8-git-send-email-daniel.kiper@oracle.com> <58E792D5020000780014E7D1@prv-mh.provo.novell.com> <20170413141125.GN16658@olila.local.net-space.pl> In-Reply-To: <20170413141125.GN16658@olila.local.net-space.pl> --RLQFH7DUOqEhVl3HiUE6AfAfWrqnhlhQE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/13/17 9:11 AM, Daniel Kiper wrote: > On Fri, Apr 07, 2017 at 05:23:33AM -0600, Jan Beulich wrote: >>>>> On 21.02.17 at 20:19, wrote: >>> Every multiboot protocol (regardless of version) compatible image mus= t >>> specify its load address (in ELF or multiboot header). Multiboot prot= ocol >>> compatible loader have to load image at specified address. However, t= here >>> is no guarantee that the requested memory region (in case of Xen it s= tarts >>> at 2 MiB and ends at ~5 MiB) where image should be loaded initially i= s a RAM >>> and it is free (legacy BIOS platforms are merciful for Xen but I foun= d at >>> least one EFI platform on which Xen load address conflicts with EFI b= oot >>> services; it is Dell PowerEdge R820 with latest firmware). To cope wi= th that >>> problem we must make Xen early boot code relocatable and help boot lo= ader to >>> relocate image in proper way by suggesting, not requesting specific l= oad >>> addresses as it is right now, allowed address ranges. This patch does= >>> former. >>> It does not add multiboot2 protocol interface which is done in "x86: = add >>> multiboot2 protocol support for relocatable images" patch. >>> >>> This patch changes following things: >>> - %esi register is used as a storage for Xen image load base addres= s; >>> it is mostly unused in early boot code and preserved during C fun= ctions >>> calls in 32-bit mode, >>> - %fs is used as base for Xen data relative addressing in 32-bit co= de >>> if it is possible; %esi is used for that thing during error print= ing >>> because it is not always possible to properly and efficiently >>> initialize %fs. >>> >>> Signed-off-by: Daniel Kiper >> >> Reviewed-by: Jan Beulich >=20 > It looks that everything passed through test gate and landed in master.= > So, this way we have full multiboot2 support in Xen. This means that > you can boot Xen using GRUB2 on EFI platforms. >=20 > I would like to thank everybody who helped me to make it happen. > Especially Jan who patiently reviewed whole series many times > and replied for my stupid questions. >=20 > Daniel >=20 Congrats Daniel. --=20 Doug Goldstein --RLQFH7DUOqEhVl3HiUE6AfAfWrqnhlhQE-- --5ld2fOgIJouV3oluBWo2XUKdlTewlxSDm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJY79TdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUK+sP/jWnCHgAlDZRdJZEf9gVU38p ohM6UUUteNonb3lkiZZF3DVccTykvIUzm1iClixlEt22zjfk7mpOoS/Pu3/H9d5y BeHRXfTzO1r+e9B9KF3o3X1t+vqtJD2Y6eYbhdPFh6SWHeBduHRG4k65Baqds0+5 e43RuK+ffSsrO8GX9zsuyI/v9kwRfXPr6bRZ81M2jiw/R7OSFmwMP6mtvGV+Sfzk Xc+IsKsP/zCZdfFpfwdTvri84xW10QR+vNYF8VcvUv9HZKgjnMhvav9cmg3OYm7b /Tghcc44hGOOvngl4A4TV4VMrOiljASKTKkGKc4x2dP00q784Jtc+EUbeKTLnbWT JNZ6q0qWOnGJdGq07KgYW2xl6MpBB+nPjACxcXKd7fWzo09dTgGBeRKKqG2H8FeQ 3ZErQAnDZk7gPIusEmNz9MSGiCpiHmlLnut9UNAeo/jPdF5B0SviOuRLlNE+uYd6 ySvE30J6eYxNtzkrhCsRgsf+UmqS+3asvr59dPcrf2s05ym7d18CSwVglr8/bSPO nUmFwa4R8ZsLkoMaGp+RJPi5VaqjO5G4cmAFIP7tYA9laSN2lo5+eHzHaoDm9UbY gQIBCvkzfQiDSgNvhGsEqmt89i9erO8Gt1SA36UV/Ab5Af+VTZ4c7Zc5Kid4L60v tE2OdmH73qCTlM66TMw4 =LNWe -----END PGP SIGNATURE----- --5ld2fOgIJouV3oluBWo2XUKdlTewlxSDm-- --===============4958803180747191985== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============4958803180747191985==--