Bring back bzImage direct kernel boot support for x86_64

[snue]

Fixes: #5766

This feature was previously removed in favor of just supporting uncompressed PVH ELF binaries for simplicity. However, direct bzImage support has a couple benefits that would be nice.

• No need to keep uncompressed images around
• Ability to use the distro provided kernel from /boot directly

By using the regular 32 bit entry point, the necessary code changes are rather small. Most of the machine setup can be shared with the PVH setup. We just need to provide the zero page and point to it in the initial register state. The boot variant is auto-detected with no further switches needed. I opted to just use the availability of the setup_header as a marker for the boot protocol instead of an explicit enum (as was done before). While being explicit is mostly good, here it would lead to more code churn and more special cases to handle.

Most of this code is a partial revert of the previously existing code.

I ran the x86_64 integration tests using both vmlinux and bzImage as the direct boot kernel with the same results as far as I could get those to work (using ./scripts/dev_cli.sh docker setup). I added one simple boot test that uses the bzImage explicitly in the integration tests.

For visibility: @parthy @blitz

[snue]

Note: It is possible to combine the initial register state to point to the PVH start info and the zero page at the same time. But this violates some of the stated assumptions on initial register state from the protocols. It works just fine with regular Linux kernels, but someone somewhere might get very unhappy, so I decided to switch it correctly.

[snue]

This was providing the actual cmdline length previously, but that's harder to get now, since the code changed a bit. This value only goes into the zero page for the guest kernel to interpret, and I verified the kernels see a correct cmdline. There might still be concerns about that, though.

[snue]

I obviously forgot to fix some tests after the rebase from LTS. I'll take care of those (as well as the missing sign-off). But let me know if you have other fundamental issues with bringing back bzImage support this way.

[blitz]

This is so nice! I've booted the NixOS netboot binaries without issue:

cloud-hypervisor on  bzimage [?] is 📦 v37.0.0 via 🦀 v1.76.0 took 7s 
❯ gh pr checkout 6200
cloud-hypervisor on  bzimage [?] is 📦 v37.0.0 via 🦀 v1.76.0 took 2s 
❯ cargo run -- --memory size=8192M --kernel ~/src/own/nixpkgs/nixos/result/bzImage --initramfs ~/src/own/nixpkgs/nixos/result/initrd --serial file=stdio --cmdline "init=/nix/store/x4b3wwnjg6nnw5qmwya3lrkaq3mc3341-nixos-system-nixos-24.05pre130979.gfedcba/init initrd=initrd nohibernate loglevel=4"
   Compiling cloud-hypervisor v37.0.0 (/home/julian/src/own/cloud-hypervisor)
    Finished dev [unoptimized + debuginfo] target(s) in 1.35s
     Running `target/debug/cloud-hypervisor --memory size=8192M --kernel /home/julian/src/own/nixpkgs/nixos/result/bzImage --initramfs /home/julian/src/own/nixpkgs/nixos/result/initrd --serial file=stdio --cmdline 'init=/nix/store/x4b3wwnjg6nnw5qmwya3lrkaq3mc3341-nixos-system-nixos-24.05pre130979.gfedcba/init initrd=initrd nohibernate loglevel=4'`


<<< Welcome to NixOS 24.05pre130979.gfedcba (x86_64) - hvc0 >>>
The "nixos" and "root" accounts have empty passwords.

To log in over ssh you must set a password for either "nixos" or "root"
with `passwd` (prefix with `sudo` for "root"), or add your public key to
/home/nixos/.ssh/authorized_keys or /root/.ssh/authorized_keys.

If you need a wireless connection, type
`sudo systemctl start wpa_supplicant` and configure a
network using `wpa_cli`. See the NixOS manual for details.


nixos login: nixos (automatic login)


[nixos@nixos:~]$

[blitz]

@rbradford Do you have a suggestion how to workaround the commit message check failure?

 7: B1 Line exceeds max length (76>72): "Signed-off-by: Stefan Nuernberger <stefan.nuernberger@cyberus-technology.de>"

[rbradford]

@rbradford Do you have a suggestion how to workaround the commit message check failure?

 7: B1 Line exceeds max length (76>72): "Signed-off-by: Stefan Nuernberger <stefan.nuernberger@cyberus-technology.de>"

The commit message check is not a blocking check - it's only there to check that nothing has gone wrong. You don't need to do anything.

[rbradford]

Thanks for your PR. FYI, we don't generally review a PR until most of the checks are green - I think you have a build issue under the snp_sev feature.

[snue]

Thanks for your PR. FYI, we don't generally review a PR until most of the checks are green - I think you have a build issue under the snp_sev feature.

Thanks for letting me know. Yes I spotted the build issue. I'll fix it in time and will be looking forward to further feedback.

[rbradford]

I'm fine with this - thank you for your contribution!