WIP: qubes-vmm-xen: init at 4.19.0-3, qubes-seabios: init at 4.0.2

[SigmaSquadron]

Description of changes

The first (and hopefully the last) custom Xen to be built based on the generic Xen builder. It's just a standard build of Xen with a lot of patches.

Compliments #341215.
Depends on #345192, #345324 and #342692.
Fixes #340544.

Things done

• Built on platform(s)
  • x86_64-linux
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review pr 341429". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • This package is a minor addition. Any release notes should go to the main Qubes PR by Yaroslav.
• Fits CONTRIBUTING.md.

cc @CertainLach

---

Add a 👍 reaction to pull requests you find important.

[SigmaSquadron]

TODO:

• Make sure the patches are all the changes that must be made to the package. (and nothing is hiding on the RPM build spec)
• Figure out nixpkgs-vet:

  If the path being referenced is internal and has multiple uses, consider passing the file as an explicit callPackage argument in pkgs/top-level/all-packages.nix.

  • I wonder how stupid would it be to do something like makeXenPackage. Some other time, perhaps. Let's just not put it in by-name for now.
• Test the custom hypervisor with Qubes packages (Its alive!) #341215 and see if anything is fixed/broken when compared to vanilla Xen.
  • SeaBIOS needed patching.
• Make sure meta is functional.

[CertainLach]

++ lib.lists.optional withSeaBIOS "--with-system-seabios=${seabios}/share/seabios"
Is wrong, it should point to seabios file, not to the directory with it:
2024-09-14 17:03:28.955+0000: libxl: libxl_utils.c:348:libxl_read_file_contents: /nix/store/v1h1jgzlpcvn8rsslzb1fsr9gwv3wbpd-seabios-1.16.3/share/seabios is not a plain file: No such file or directory

Changing it to
++ lib.lists.optional withSeaBIOS "--with-system-seabios=${seabios}/share/seabios/Csm16.bin"
Fixes that problem.

I'm not sure if that's qubes changes, or system seabios flag is broken in xen derivation itself.

Interestingly, in qubes, this directory is populated with bios{-256k,-coreboot,-csm,-microvm,}.bin files, I wonder how is correct.

EDIT: Nvm, I think current behavior is correct, I'll provide fixes and qubes-seabios package in my PR.

[CertainLach]

qubes-vmm-xen.passthru.efi has value "boot/xen-4.19.0-3.efi", but the file is in fact called "boot/xen-4.19.0.efi"

In qubes-packages PR I fix that by using

--- a/pkgs/by-name/qu/qubes-vmm-xen/package.nix
+++ b/pkgs/by-name/qu/qubes-vmm-xen/package.nix
@@ -11,7 +11,9 @@
 let
   pname = "qubes-vmm-xen";
   branch = "4.19";
-  version = "4.19.0-3";
+  versionPatches = "4.19.0";
+  versionSuffix = "3";
+  version = "${versionPatches}-${versionSuffix}";
   latest = true;
 
   xenPatches = import ../../../applications/virtualization/xen/generic/patches.nix {
@@ -43,7 +45,7 @@ let
   python = python311;
 in
 
-callPackage
+(callPackage
   (import ../../../applications/virtualization/xen/generic/default.nix {
     inherit
       pname
@@ -108,3 +110,8 @@ callPackage
     }
     // genericDefinition
   )
+).overrideAttrs (oldAttrs: {
+  passthru = oldAttrs.passthru // {
+    efi = "boot/xen-${versionPatches}.efi"
+  };
+})

[SigmaSquadron]

qubes-vmm-xen.passthru.efi has value "boot/xen-4.19.0-3.efi", but the file is in fact called "boot/xen-4.19.0.efi"

oops. fixed.

[CertainLach]

I believe seabios comment is relevant after all.

In my qubes branch, I was only able to use Xen with this argument specified:
https://github.com/NixOS/nixpkgs/pull/341215/files#diff-22074e16d7355ea382a13e722d42183c6f0655b57f7ffbe15c562d0f7977fb69R438

[SigmaSquadron]

The label works!

[SigmaSquadron]

Moved the generic stuff to #345192.

[SigmaSquadron]

hmmmmm

Considering Xen explicitly says non-i386 DMs aren't well-tested, why is Qubes using x86_64?

[CertainLach]

Qubes usually uses dm-stubdom with i386 model inside, I don't know where is this qemu is being used at all.