Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Thu, Jan 12, 2017 at 04:20:00PM -0600, Doug Goldstein wrote:
> On 1/12/17 3:45 PM, Daniel Kiper wrote:
> > On Thu, Jan 12, 2017 at 01:46:41PM -0600, Doug Goldstein wrote:
> >> On 1/12/17 1:30 PM, Daniel Kiper wrote:
> >>> On Thu, Jan 12, 2017 at 09:44:59AM -0600, Doug Goldstein wrote:
> >>>> view there's no reason for adding MB2 support for BIOS since it provides
> >>>> no advantage over MB1 when booting from the BIOS. Now MB2 solves a
> >>>
> >>> 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 can 
> >>> boot Xen
> >>> on both platforms without changing anything in boot config files. 
> >>> Otherwise 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.
> >
> > Hmmm... This is interesting. I do not know iPXE, however, in GRUB you must
> > use multiboot/module for MB1 and multiboot2/module2 for MB2. I suppose that
> > you have to differentiate between both of them in iPXE somehow too. Hence,
> > there is pretty good chance that configs for MB1 and MB2 are different.
>
> multiboot/multiboot2 and module/module2 are aliases of each other. They
> work interchangeably. Its the same way in iPXE.

If you carefully look at GRUB2 code and how multiboot and multiboot2
modules are build you quickly realize that they are not aliases.
Though I do not how it works in iPXE.

> >>>> 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 with
> >>>> 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 structure.
> >>>
> >>> 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_TYPE_MMAP (same
> >>> as MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO), 
> >>> MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME
> >>> (same as MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO) ,MULTIBOOT2_TAG_TYPE_CMDLINE,
> >>> MULTIBOOT2_TAG_TYPE_MODULE. I do not mention MULTIBOOT2_TAG_TYPE_END which
> >>> is obvious. So, if you are real hardcore minimalist then you have to 
> >>> provide
> >>> 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 MB2
> >>> for legacy BIOS. And I do not think that it is very difficult to provide
> >>> 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
> >
> > I showed you that if you are real minimalist you can enable the same MB2 
> > code
> > on legacy BIOS and EFI. I do not understand your objection against providing
> > MB2 in iPXE on legacy BIOS if you do not need extra code (maybe a few 
> > #ifdefs).
> > Though I am not going to convince you. It is your choice but I am still 
> > thinking
> > that it is wrong choice.
>
> Its not my choice. Its the feedback I've received from upstream.

OK, they are iPXE maintainers. Though it still does not change my
opinion about their decision.

> > By the way, does iPXE check MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST in 
> > Xen header.
> > If it does (it should) and do not understand 
> > MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO and
> > MULTIBOOT2_TAG_TYPE_MMAP then it should fail.
>
> It does but I know that Xen doesn't use that information if Boot
> Services are available by code inspection. Which is what my comments are
> related to.

I am not sure that you correctly understood what I mean. Please read
multiboot2 "Information request header tag" section for more details.
iPXE should obey this rule even if you do not provide 
MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
and MULTIBOOT2_TAG_TYPE_MMAP. The same is relevant for other tags in
image header. To be precise: I mean that iPXE should complain if it
sees __REQUESTS__ for unknown tags.

> >> 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.
> >
> > How come... Which GRUB version do you use? Xen clearly says that it needs
> > boot services (look into MB2 header). So, GRUB is not allowed to call
> > ExitBootServices(). If it does then it is GRUB bug.
>
> No. That's not how it works at all. To quote 3.1.12 of the Multiboot2
> spec...
>
> "This tag indicates that payload supports starting without terminating
> boot services."
>
> This tag is not required to be respected but instead means that the
> payload supports using boot services. Additionally section 3.6.3 which

Ahhh... Right, I forgot about that.

> talks about passing MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO states...
>
> "This tag may not be provided by some boot loaders on EFI platforms if
> EFI boot services are enabled and available for the loaded image (EFI
> boot services not terminated tag exists in Multiboot2 information
> structure)."
>
> And section 3.6.8 talks about passing MULTIBOOT2_TAG_TYPE_MMAP states...
>
> "This tag may not be provided by some boot loaders on EFI platforms if
> EFI boot services are enabled and available for the loaded image (EFI
> boot services not terminated tag exists in Multiboot2 information
> structure)."
>
> So for my iPXE support if the payload (in this case Xen) reports that it
> supports not having boot services exited then I don't exit it and I
> don't provide MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO or
> MULTIBOOT2_TAG_TYPE_MMAP. Considering the fact that if Xen has boot
> services available it ignores these two tags it seems what I've done
> complies with the spec and complies with the only known full
> implementation of MB2. (fwiw, the only implementations I know about are
> tboot and your Xen patches. I've written a small application which dumps
> out the data that was received but that was purely for debugging).

Yep, you can do that and I have never ever said that you have to provide both
above mentioned tags. Even on legacy BIOS platforms.

> >> 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 well.
> >
> > OK, this is a bug and I will fix it. However, this is not related to
> > ExitBootServices() call in GRUB2.
>
> Well it is. Because if boot services are not available then to goes the
> path of the bug.

By chance you have triggered this bug by shutting down boot services in the
boot loader but it is also possible to do that in a bit different way
unrelated to the EFI stuff at all.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel