allod/vm
2
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

Remove hardcoded CPU architecture values #1

New issue
Open
opened 2026-07-09 23:37:22 +01:00 by vnprc-agent · 0 comments
vnprc-agent commented 2026-07-09 23:37:22 +01:00
Copy link

User story: So that I can run the VM framework on supported CPU architectures, shared modules should derive platform and virtualization settings instead of assuming one architecture family.

Part of the "Profiles & VM archetypes" arc.

The vm framework hardcodes x86_64-linux (and Intel-specific KVM) in several
places. This blocks the aarch64-linux host support the framework otherwise
advertises, and bakes CPU assumptions into shared modules. These should be
parameterized so the framework evaluates and builds for any supported system.

Hardcoded values

  • flake.nix:25 — apps.x86_64-linux.agenix pins the app output to a single system.
  • flake.nix:27 — program = "${agenix.packages.x86_64-linux.agenix}/bin/agenix" pins the package system.
  • modules/qemu-guest.nix:18 — nixpkgs.hostPlatform = lib.mkDefault "x86_64-linux" bakes an x86_64 default for the guest platform.
  • modules/qemu-guest.nix:16 — boot.kernelModules = [ "kvm-intel" ] assumes an Intel x86 host (AMD needs kvm-amd; aarch64 needs neither).

Suggested approach

  • Iterate the agenix app over supported systems (e.g. flake-utils.lib.eachDefaultSystem, or genAttrs over a systems list) instead of hardcoding x86_64-linux.
  • Take the guest nixpkgs.hostPlatform from consumer/inventory data (the machine's platform) rather than a baked default.
  • Make the KVM kernel module platform/vendor-aware, or move it to the consumer's hardware configuration where the CPU vendor is known.
  • Consider adding a no-hardcoded-arch flake check (as nexus has) that greps framework modules for literal Nix system strings, to prevent regressions.

README.md references x86_64-linux as well and should follow once the code is parameterized.

**User story:** So that I can run the VM framework on supported CPU architectures, shared modules should derive platform and virtualization settings instead of assuming one architecture family. _Part of the "Profiles & VM archetypes" arc._ --- The `vm` framework hardcodes `x86_64-linux` (and Intel-specific KVM) in several places. This blocks the `aarch64-linux` host support the framework otherwise advertises, and bakes CPU assumptions into shared modules. These should be parameterized so the framework evaluates and builds for any supported system. ## Hardcoded values - `flake.nix:25` — `apps.x86_64-linux.agenix` pins the app output to a single system. - `flake.nix:27` — `program = "${agenix.packages.x86_64-linux.agenix}/bin/agenix"` pins the package system. - `modules/qemu-guest.nix:18` — `nixpkgs.hostPlatform = lib.mkDefault "x86_64-linux"` bakes an x86_64 default for the guest platform. - `modules/qemu-guest.nix:16` — `boot.kernelModules = [ "kvm-intel" ]` assumes an Intel x86 host (AMD needs `kvm-amd`; `aarch64` needs neither). ## Suggested approach - Iterate the `agenix` app over supported systems (e.g. `flake-utils.lib.eachDefaultSystem`, or `genAttrs` over a systems list) instead of hardcoding `x86_64-linux`. - Take the guest `nixpkgs.hostPlatform` from consumer/inventory data (the machine's `platform`) rather than a baked default. - Make the KVM kernel module platform/vendor-aware, or move it to the consumer's hardware configuration where the CPU vendor is known. - Consider adding a `no-hardcoded-arch` flake check (as `nexus` has) that greps framework modules for literal Nix system strings, to prevent regressions. `README.md` references `x86_64-linux` as well and should follow once the code is parameterized.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
agent/codex-package-update
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
allod/vm#1
No description provided.