Page MenuHomeFreeBSD

loader: implement multiboot support for Xen Dom0
ClosedPublic

Authored by royger on Aug 1 2014, 1:54 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Jun 9, 10:50 AM
Unknown Object (File)
Sun, Jun 9, 10:08 AM
Unknown Object (File)
Fri, Jun 7, 4:14 AM
Unknown Object (File)
Apr 29 2024, 5:07 PM
Unknown Object (File)
Apr 28 2024, 9:56 PM
Unknown Object (File)
Apr 28 2024, 10:05 AM
Unknown Object (File)
Apr 24 2024, 4:55 PM
Unknown Object (File)
Mar 28 2024, 8:29 AM
Subscribers
None

Details

Reviewers
kib
emaste
jhb
Summary

Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.

In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.

The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.

Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.

The way to load a FreeBSD Dom0 from the bootloader is the following,
first we must make sure nothing else has been loaded, and then we can
load in the following order the Xen microkernel, FreeBSD and whatever
modules are needed in order to boot:

unload
load /boot/xen
load kernel
load zfs
load if_tap
load ...
boot

The arguments that are passed to the Xen kernel can be set from both
the command line at load time:

load /boot/xen dom0_mem=1024M dom0pvh=1

Or by setting the following variable in the /boot/loader.conf file:

xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 com1=115200,8n1 console=com1"

The only missing piece here is the ability to tell the loader to boot
directly into Xen. I was thinking of adding something like the
following to /boot/loader.conf to make it boot automatically into Xen:

xen_kernel="/boot/xen"

However, I haven't been able to implement it because AFAICT it should
be done in forth, and I'm not even able to figure out what's a

function, a variable or a conditional in that language.

A couple of notes on the coding style:

Several files on sys/boot have a very bad style, mixing hard tabs
with spaces, the newly added multiboot files only use hard tabs
following the FreeBSD kernel coding style.

For the other bits that I've modified, I've tried to do my best to
adapt to the style of the surrounding code.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

royger retitled this revision from to loader: implement multiboot support for Xen Dom0.
royger updated this object.
royger edited the test plan for this revision. (Show Details)
royger added reviewers: emaste, kib.

I've already committed all the required kernel changes in order to boot FreeBSD as a PVH Dom0, and I would like to get some review/feedback on this change so all the basic bits are committed and people can start testing it :).

I really do not know the code of loader proper. I only rewrote btx once.

Cursory look of the ELF parsing and interpreting code did not caused me to note anything outstanding.

sys/boot/common/load_elf.c
238–242

Just if (multiboot) ? And use bool instead int as type.

sys/boot/common/module.c
142

Fix style while changing the line, add space between return and (.

sys/boot/i386/libi386/multiboot_tramp.S
1

Is the note that multiboot_tramp.S was copied from metadata.h is some artefact of review system ? I do not think that there is any use of glueing .h and .S files history.
What parts of tramp.S were written by Peter ?

I've fixed the nits pointed out by kib and uploaded the patch, this should be easier to read since there will be no phabricator artifacts:

https://people.freebsd.org/~royger/0001-loader-implement-multiboot-support-for-Xen-Dom0.patch

sys/boot/common/load_elf.c
238–242

bool/boolean_t types are not defined by sys/types.h when included outside of the kernel code. I can look into modifying types.h to declare them. I just felt it was too much fuss and was afraid of breaking other stuff.

sys/boot/common/module.c
142

Done.

sys/boot/i386/libi386/multiboot_tramp.S
1

No, multiboot_tramp.S is certainly not copied from metadata.h, not sure what phabricator is doing here.

The file was based on amd64_tramp.S, but I don't think there are any remains of it, so I will remove the copyright.

royger edited edge metadata.

Fixed the nits pointed out by kib.

Added the forth bits in order to automatically load Xen and FreeBSD by
setting the xen_kernel loader env variable (this code has been contributed
by Julien Grall as stated on the commit message).

I've also updated the patch at:

https://people.freebsd.org/~royger/0001-loader-implement-multiboot-support-for-Xen-Dom0.patch

Hello,

I've already pushed all the kernel changes needed in order to have basic PVH Dom0 support, and this is the last change needed in order to boot a FreeBSD PVH Dom0. I've been testing this for almost 6 months without any issues, so unless someone has any comments on it I plan to push it before then end of the week. Last version can be found on my git repo:

http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=commit;h=1c581e7f9c29e577d2e17686d6e28bf7d3df5286

jhb edited edge metadata.

I think this looks fine from what I can tell.

sys/boot/i386/libi386/multiboot_tramp.S
2

This should probably just be a new file rather than a copy of metdata.h?

This revision is now accepted and ready to land.Dec 15 2014, 5:11 PM
royger added inline comments.
sys/boot/i386/libi386/multiboot_tramp.S
2

I'm not sure why phabric thinks this is a copy of metadata.h, according to my git tree this is a new file.