Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

set up multiboot information structure #4

Closed
6 of 11 tasks
fabianfreyer opened this issue Feb 15, 2018 · 2 comments
Closed
6 of 11 tasks

set up multiboot information structure #4

fabianfreyer opened this issue Feb 15, 2018 · 2 comments
Labels
help wanted Extra attention is needed spec
Milestone

Comments

@fabianfreyer
Copy link
Contributor

fabianfreyer commented Feb 15, 2018

  • if the os image requests it
    • get the upper and lower memory using

      bhyve-multiboot/userboot.h

      Lines 186 to 190 in ff5a9bc

      /*
      * Return guest physical memory map details
      */
      void (*getmem)(void *arg, uint64_t *lowmem,
      uint64_t *highmem);
    • set mbi->mem_lower and mbi->mem_upper and set bit 0 of mbi->flags.
    • generate a memory map buffer as described in the multiboot spec, point mbi->mmap_addr to it, set mbi->mmap_length, and set bit 6 of mbi->flags.
  • make sure bit 1 of mbi->flags is cleared, as specified:

    If bit 1 in the ‘flags’ word is set, then the ‘boot_device’ field is valid, and indicates which bios disk device the boot loader loaded the OS image from. If the OS image was not loaded from a bios disk, then this field must not be present (bit 3 must be clear).

  • if cmdline is given, copy it into the hypervisor, and set mbi->cmdline and set bit 2 of mbi->flags.
  • if modules are given, parse their command-line specification and load them:
    • copy them into the guest, page-align them if requested by the kernel.
    • set up an array of module structures, point mbi->mods_addr to it and set mbi->mods_count
  • set bit 9 of mbi->flags. copy the bootloader name into the guest and point mbi->boot_loader_name to it.
  • if the kernel requests it, set up video modes - although it isn't clear what this means for headless systems.
@fabianfreyer fabianfreyer added help wanted Extra attention is needed spec labels Feb 15, 2018
@fabianfreyer fabianfreyer added this to the v0.1 milestone Feb 15, 2018
@fabianfreyer
Copy link
Contributor Author

For the bhyve memory map, see grub2-bhyve's implementation:

  /*
   * bhyve is going to return the following memory segments
   *
   * 0 - 640K    - usable
   * 640K- 1MB   - vga hole, BIOS, not usable.
   * 1MB - lomem - usable
   * lomem - 4G  - not usable
   * 4G - himem  - usable [optional if himem != 0]
   */
  bhyve_info.nsegs = 2;
  bhyve_info.segs = bhyve_mm;

  bhyve_mm[0].start = 0x0;
  bhyve_mm[0].end = 640*1024;		/* 640K */
  bhyve_mm[0].type = GRUB_MEMORY_AVAILABLE;

  bhyve_mm[1].start = 1024*1024;
  bhyve_mm[1].end = (memsz > lomemsz) ? lomemsz : memsz;
  bhyve_mm[1].type = GRUB_MEMORY_AVAILABLE;

  if (memsz > lomemsz) {
    bhyve_info.nsegs++;
    bhyve_mm[2].start = 4*GB;
    bhyve_mm[2].end = (memsz - lomemsz) + bhyve_mm[2].start;
    bhyve_mm[2].type = GRUB_MEMORY_AVAILABLE;
  }

@fabianfreyer
Copy link
Contributor Author

Seeing as qemu doesn't support vbe either, I think we can break with the spec here and just error out:

From qemu's hw/i386/multiboot.c:

if (flags & 0x00000004) { /* MULTIBOOT_HEADER_HAS_VBE */
    fprintf(stderr, "qemu: multiboot knows VBE. we don't.\n");
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed spec
Projects
None yet
Development

No branches or pull requests

1 participant