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

Bionic (EFI booting) fails to boot with master and cloud-hypervisor #35

Closed
rbradford opened this issue Mar 30, 2020 · 0 comments · Fixed by #36
Closed

Bionic (EFI booting) fails to boot with master and cloud-hypervisor #35

rbradford opened this issue Mar 30, 2020 · 0 comments · Fixed by #36

Comments

@rbradford
Copy link
Member

After merging #26 the bionic image which uses EFI to boot no longer boots. I did a bisect to find the cause but some of commits failed to build. Here is what bisect suggests are the possible commits:

rob@rbradford-test:~/rust-hypervisor-firmware$ git bisect visualize
commit e3873908a69622001e35b6e1f85ee8fdb28d9fbf (HEAD, refs/bisect/bad)
Author: Joe Richey <[email protected]>
Date:   Sat Mar 28 19:30:22 2020 -0700

    main: Rewrite boot_from_device
    
    We now pass the boot::Info to `loader::load_default_entry` and
    `efi::efi_exec`. We also reorganize the code in this function to:
      - Avoid unnecessary nesting
      - log errors when they occur
    
    The code is now much more readable
    
    Signed-off-by: Joe Richey <[email protected]>

commit 1ff201b9d5bfa1ccdb911bd718203dee74a5e661 (refs/bisect/skip-1ff201b9d5bfa1ccdb911bd718203dee74a5e661)
Author: Joe Richey <[email protected]>
Date:   Sat Mar 28 18:54:55 2020 -0700

    bzimage: Rewrite Linux Kernel Loading code
    
    This allows Linux to be booted with any boot protocol.
    
    The old code took in the Zeropage passed in via the Linux Kernel Boot
    Protocol, modified it, and passed it into the Linux Kernel. This is not
    the correct way to boot Linux per the documentation:
        https://www.kernel.org/doc/Documentation/x86/boot.txt
    
    This code now correctly:
      - Uses a brand-new Zeropage inside the `Kernel` struct
      - Adds in the E820 map and RSDP pointer from the boot::Info
      - Reads the header from the file and copies it into the Zeropage
      - Loads the kernel and initrd into avalible memory
      - Properly manages the command-line at a fixed memory location
      - Jumps to the appropriate starting address
    
    Signed-off-by: Joe Richey <[email protected]>

commit e2d541041e11dc885ce8619c7cb811b7151e6e03 (refs/bisect/skip-e2d541041e11dc885ce8619c7cb811b7151e6e03)
Author: Joe Richey <[email protected]>
Date:   Sat Mar 28 17:53:35 2020 -0700

    efi: Use Info to setup allocator and EFI tables
    
    This allows efi_exec to work with multiple boot protocols.
    
    Signed-off-by: Joe Richey <[email protected]>

Here is the output

Booting via PVH Boot Protocol
Setting up 4 GiB identity mapping
Page tables setup
Found PCI device vendor=8086 device=d57 in slot=0
Found PCI device vendor=1af4 device=1042 in slot=1
Found PCI device vendor=1af4 device=1044 in slot=2
PCI Device: 0:1.0 1af4:1042
Bar: type=MemorySpace32 address=e7f80000
Bar: type=MemorySpace32 address=0
Bar: type=MemorySpace32 address=0
Bar: type=MemorySpace32 address=0
Bar: type=MemorySpace32 address=0
Bar: type=Unused address=0
Virtio block device configured. Capacity: 4612096 sectors
Found EFI partition
Filesystem ready
Error loading default entry: FileError(NotFound)
Using EFI boot.
Found bootloader (BOOTX64.EFI)
Executable loaded

It appears to be failing to jump to run the EFI binary itself.

I also forced it to use Linux boot vs PVH boot and got the same result (by reverting the addition of the PVH note.)

@josephlr would you mind taking a look please?

rbradford added a commit to rbradford/rust-hypervisor-firmware that referenced this issue Apr 1, 2020
There is no need to reset the device as Cloud Hypervisor supports device
reset itself (so the booted kernel will correctly reset the device on
boot.)

In particular resetting the block device prior to booting via EFI breaks
the EFI boot.

Fixes: cloud-hypervisor#35

Signed-off-by: Rob Bradford <[email protected]>
rbradford added a commit that referenced this issue Apr 1, 2020
There is no need to reset the device as Cloud Hypervisor supports device
reset itself (so the booted kernel will correctly reset the device on
boot.)

In particular resetting the block device prior to booting via EFI breaks
the EFI boot.

Fixes: #35

Signed-off-by: Rob Bradford <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant