From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms Date: Thu, 12 Jan 2017 13:46:41 -0600 Message-ID: References: <1480976718-12198-1-git-send-email-daniel.kiper@oracle.com> <1480976718-12198-8-git-send-email-daniel.kiper@oracle.com> <96e86b22-8940-dce2-d1b9-92d1c132ad0e@cardoe.com> <20170111190821.GY32675@olila.local.net-space.pl> <5a54299d-240d-5783-9a3b-5c3504d6fa4e@cardoe.com> <20170112121807.GF32675@olila.local.net-space.pl> <216aee7d-f0ab-3ba1-3c00-c16e211fecc7@cardoe.com> <20170112193037.GI32675@olila.local.net-space.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0660322957482168318==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRmNR-000171-Nr for xen-devel@lists.xenproject.org; Thu, 12 Jan 2017 20:53:41 +0000 Received: by mail-io0-f194.google.com with SMTP id q20so3642960ioi.3 for ; Thu, 12 Jan 2017 12:53:38 -0800 (PST) In-Reply-To: <20170112193037.GI32675@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 Cc: jgross@suse.com, sstabellini@kernel.org, andrew.cooper3@citrix.com, pgnet.dev@gmail.com, ning.sun@intel.com, julien.grall@arm.com, jbeulich@suse.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) --===============0660322957482168318== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ipHL7HFVoJc5GiQlAdxW7UePgg0UTVOX3" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ipHL7HFVoJc5GiQlAdxW7UePgg0UTVOX3 Content-Type: multipart/mixed; boundary="egoi7PW8t7NDvowDsFnIQJP53Al9Ux7T8"; protected-headers="v1" From: Doug Goldstein To: Daniel Kiper Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, fu.wei@linaro.org, gang.wei@intel.com, jbeulich@suse.com, jgross@suse.com, julien.grall@arm.com, konrad.wilk@oracle.com, ning.sun@intel.com, pgnet.dev@gmail.com, qiaowei.ren@intel.com, sstabellini@kernel.org Message-ID: Subject: Re: [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms References: <1480976718-12198-1-git-send-email-daniel.kiper@oracle.com> <1480976718-12198-8-git-send-email-daniel.kiper@oracle.com> <96e86b22-8940-dce2-d1b9-92d1c132ad0e@cardoe.com> <20170111190821.GY32675@olila.local.net-space.pl> <5a54299d-240d-5783-9a3b-5c3504d6fa4e@cardoe.com> <20170112121807.GF32675@olila.local.net-space.pl> <216aee7d-f0ab-3ba1-3c00-c16e211fecc7@cardoe.com> <20170112193037.GI32675@olila.local.net-space.pl> In-Reply-To: <20170112193037.GI32675@olila.local.net-space.pl> --egoi7PW8t7NDvowDsFnIQJP53Al9Ux7T8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/12/17 1:30 PM, Daniel Kiper wrote: > On Thu, Jan 12, 2017 at 09:44:59AM -0600, Doug Goldstein wrote: >=20 >> view there's no reason for adding MB2 support for BIOS since it provid= es >> no advantage over MB1 when booting from the BIOS. Now MB2 solves a >=20 > From your point of view maybe it does not. However, from user point of = view it may. > If you have support for MB2 on legacy BIOS and EFI platforms then you c= an boot Xen > on both platforms without changing anything in boot config files. Other= wise you have > to prepare separate configuration for different platforms. Neither Grub nor iPXE require different configs for MB1 vs MB2 so I'm not seeing the validity of this logic. >=20 >> problem with booting over EFI vs MB1 so they'll be willing to take a >> change there. I'll also disagree that BIOS is easier than EFI since wi= th >> EFI its just load the ELF into memory and set a few pointers in tags. >> With BIOS it requires me to build up the memory map into a MB2 structu= re. >=20 > Xen uses only these tags on legacy BIOS platforms: MULTIBOOT2_TAG_TYPE_= BASIC_MEMINFO > (well, nice to have but it can be also not provided), MULTIBOOT2_TAG_TY= PE_MMAP (same > as MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO), MULTIBOOT2_TAG_TYPE_BOOT_LOADER_= NAME > (same as MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO) ,MULTIBOOT2_TAG_TYPE_CMDLIN= E, > MULTIBOOT2_TAG_TYPE_MODULE. I do not mention MULTIBOOT2_TAG_TYPE_END wh= ich > is obvious. So, if you are real hardcore minimalist then you have to pr= ovide > MULTIBOOT2_TAG_TYPE_CMDLINE and MULTIBOOT2_TAG_TYPE_MODULE. All of them= > are provided also on EFI. So, I do not see any reason to not provide MB= 2 > for legacy BIOS. And I do not think that it is very difficult to provid= e > all optional tags mentioned above. I don't understand what you're attempting to convey here. You've listed out a number of tags that I mentioned in my message that I don't have to implement for EFI. You've basically reinforced my point that its easier to implement this for EFI than BIOS. MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO and MULTIBOOT2_TAG_TYPE_MMAP are unused by Xen on EFI. It gets this info from a call to GetMemoryMap(). You actually reminded me of another bug. Calling ExitBootServices() on Grub and letting it pass the memory info causes Xen to fail to load. Andrew helped me troubleshoot this and he discovered the fix. You've got code: /* Store Xen image load base address in place accessible for 32-bit code.= */ mov %r15d,%esi But if any of the checks under the run_bs: label specifically: - /* Are EFI boot services available? */ - /* Is EFI SystemTable address provided by boot loader? */ - /* Is EFI ImageHandle address provided by boot loader? */ Will not run the mov instruction and then fail to boot. Its only if any of these are false will it attempt to use the tags mentioned above as wel= l. --=20 Doug Goldstein --egoi7PW8t7NDvowDsFnIQJP53Al9Ux7T8-- --ipHL7HFVoJc5GiQlAdxW7UePgg0UTVOX3 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 iQJ8BAEBCgBmBQJYd90nXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUBM8QAIiPhPa00e4M9fiMWww/Uh9S /twxcZvASwdaEKONUFzQ0pIfnaHUSLHGTTIyGwBOs+X8uhI5P4uEkCGkclXkncvD 788d0VUTrC9dC9cg1kUZFSelOrsfbz9bcj2pIrqMFEzYRuMVVGcbnsszhohFmYiQ qTszjkxO9/VaLuSLwHP13CKGQCnlfxaa6ybUPCN2Q/ucNNE+9HoQHBrQFwKpcxk0 eo4J45K9iO9KHmmHeR1/X3CauJNagN02rt5Yie3kEVQh84fUCbACibrDpnQ21jRv ZaHvstQ/8L4DzOJySAqU5RJHjNKvdgRNZPq3hiGJ+NcHxz0cJEy0OX57bzeXRtNb yO0btFBu4MeA+WGVvtfjuiuMUBee+NmEc15JaiOwS+OpruzpNuCIi6SJ4KZCdByS f8tfVDHZj8gqzBSu5ozYhK7jiokkvSrcU6ePOQRhYbEQlm2NQVL0fP+wYomXI+LF SS6apil+iGHwdF86Kx5uy7afJjeNgY+CGYIWOmlsMq4+FqQ5qpkxL+nvmT73OlLA 61BHbqHufZhLJ4o2nWA6OkvXTqx9qU9D1VCpc5AIC9xsUjRMDwBBxrhBxbeTeES5 4pM9Ff7kKTlNBgpUBZIIwe9fAWeqCOP/P55lpAjas26yHVN3b/yE2VvVqjJ/6vAQ GUZc4+r9mA20T+MyTrU2 =fgFS -----END PGP SIGNATURE----- --ipHL7HFVoJc5GiQlAdxW7UePgg0UTVOX3-- --===============0660322957482168318== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============0660322957482168318==--