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

[Doug Goldstein <cardoe@xxxxxxxxxx>]

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.


> 
>>>> 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.

> 
> 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.

> 
>> 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
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).


> 
>> 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.

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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