DocsReleasesCommunityGuidesBlog

GSoC'24: Linux x86 Boot Protocol Support

The Linux boot protocol plays an important role in the initialization of the Linux operating system, emphasizing the importance of system optimization and scalability.

As I wrote in the previous blog post, my first objective is to make Unikraft boot on QEMU using the Linux x86 boot protocol. Here I will present my progress so far and different challenges I faced while working towards my goal.

Where does QEMU handle the lxboot header?#

By using the git grep command, I found that QEMU 9.0.1 handles the Linux x86 boot protocol in the x86.c file. Everything happens in the x86_load_linux function.

Fields used by QEMU#

These are as follows:

  • 0x202: HEADER
  • 0x206: VERSION
  • 0x211: LOADFLAGS
  • 0x236: XLOADFLAGS
  • 0x22c: INITRD_ADDR_MAX
  • 0x228: CMD_LINE_PTR
  • 0x1fa: VID_MODE
  • 0x210: TYPE_OF_LOADER
  • 0x224: HEAP_END_PTR
  • 0x1f1: SETUP_SECTS
  • 0x250: SETUP_DATA
  • 0x218: RAMDISK_IMAGE
  • 0x21c: RAMDISK_SIZE

As you can see, only 13 out of 39 fields are used. Out of these, 6 are read by QEMU:

  • 0x202: HEADER
  • 0x206: VERSION
  • 0x211: LOADFLAGS
  • 0x236: XLOADFLAGS
  • 0x22c: INITRD_ADDR_MAX
  • 0x1f1: SETUP_SECTS

And 7 are written by QEMU:

  • 0x228: CMD_LINE_PTR
  • 0x1fa: VID_MODE
  • 0x210: TYPE_OF_LOADER
  • 0x224: HEAP_END_PTR
  • 0x250: SETUP_DATA
  • 0x218: RAMDISK_IMAGE
  • 0x21c: RAMDISK_SIZE

Debugging and testing#

The application I am using to test the mklinux_x86.py file is app-helloworld. By using multiple printf and exit calls inside the x86_load_linux function, I was able to determine the way QEMU uses the header. Another useful tool was hexdump,that was used to look at how my script builds the header.

Challenges#

For starters, I could not figure out why the header created by the script did not align to what QEMU expected. The problem was that the header, as presented in the documentation, starts at offset 0x1f1, not 0x0. To fix it I had to add 0x1f1 zeros.

Another issue was with integrating it in Unikraft. Eventually I figured it out, with help from my mentors.

Integration with Unikraft#

Although debugging could be done only by running the mklinux_x86.py script and looking at the header, I wanted to test by integrating everything in Unikraft. For doing this I had to modify the following files: Linker.uk, Config.uk and Makefile.rules.

Next steps#

At the moment, when I try to run, it loops indefinitely. I have to debug and find out what does not work.

Additionally I am going to look into SeaBIOS/qboot/GRUB2 to see how the jumping to the kernel happens and I will write the needed 16-bit and 32-bit assembly stubs.

Edit this page on GitHub

Connect with the community

Feel free to ask questions, report issues, and meet new people.

Join us on Discord!
®

Getting Started

What is a unikernel?Install CLI companion toolUnikraft InternalsRoadmap

© 2024  The Unikraft Authors. All rights reserved. Documentation distributed under CC BY-NC 4.0.