Page MenuHomeFreeBSD

stand/multiboot2: add support for booting a Xen dom0 in UEFI mode

Authored by royger on Feb 5 2021, 12:58 PM.



Add some basic multiboot2 infrastructure to the EFI loader in order to
be capable of booting a FreeBSD/Xen dom0 when booted from UEFI.

Only a very limited subset of the multiboot2 protocol is implemented
in order to support enough to boot into Xen, the implementation
doesn't intent to be a full multiboot2 capable implementation.

Such multiboot2 functionality is hooked up into the amd64 EFI loader,
which is the only architecture that supports Xen dom0 on FreeBSD.

The options to boot a FreeBSD/Xen dom0 system are exactly the same as
on BIOS, and requires setting the xen_kernel and xen_cmdline options
in loader.conf.

Sponsored by: Citrix Systems R&D

Diff Detail

R10 FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

This revision is now accepted and ready to land.Feb 5 2021, 7:49 PM

There are few concerns... not yet complete list as it is getting late for me, but hopefully it will still be helpful.


I think, we shall get more non-optional tags, do you have this list tested agains xen?

The basic idea is, the MB2 program is built with tag information request, and anything non-optional must be presented by us. So, if the program is requesting MULTIBOOT_TAG_TYPE_EFI64 as not optional, this loop will error out.


Basically here we get flagged if we should exit BS or not, that is, what boolean value we should use with bi_load().


What if some xen version does not ask us to keep BS?

Thanks for the review! Will try to fix the comments later and update.


Yes, TBH those are the only tags requested by Xen and hence are the only ones I added. Let me add the tags that we unconditionally present to the OS.


Well, if there's no keep BS flag, it's also very likely there will be a required MULTIBOOT_TAG_TYPE_EFI_MMAP in order to pass the memory map to the OS, which we don't implement right now, and will error out anyway.

I can propagate this to the exec function by using a MODINFOMD_MB2HDR blob that contains the stuff related to the multiboot2 header that we need at execution time.


It's very likely to then require a MULTIBOOT_TAG_TYPE_EFI_MMAP tag that we don't implement, so we would bail out at load time.

But yes, will add some of this information as a MB2HDR blob.

  • Introduce a mb2hdr struct to pass information between the load and the exec functions.
  • Bail out at load if there's no keep BS tag.
  • Add the tags we unconditionally set to the check in MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST.
This revision now requires review to proceed.Feb 8 2021, 11:06 AM

@tsoome let me know if you are happy with this version, as I would like to commit it soon-ish. Thanks!

This revision is now accepted and ready to land.Feb 16 2021, 10:35 AM