nixos/xen: refactor dom0 configuration

[SigmaSquadron]

Description of changes

Refactors the Xen module for Domain 0.

• Cleans up downstream systemd units in favour of using upstream units.
• Xen 4.18 on Nixpkgs now supports EFI booting, so we have an EFI boot builder here that runs after systemd-boot-builder.py.
• Add more options for setting up dom0 resource limits.
• Adds options for the declarative configuration of oxenstored.
• Disables the automatic bridge configuration, as it was broken.
• Deprecates legacy boot.

Things done

• Built on platform(s)
  • x86_64-linux
• Tested, as applicable:
  • No automated tests for NixOS/xen yet.
• 24.11 Release Notes
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
    • I added a release note under highlights. Let me know if this is too presumptuous.
• Fits CONTRIBUTING.md.

Closes #129780, closes #127404.

Add a 👍 reaction to pull requests you find important.

[JulienMalka]

This feels very intrusive to the systemd-boot-builder codebase to me, which will create maintenance burden. I've never worked with Xen, could you explain why this is necessary? Is it not possible to do the modification to the xen.cfg file at build time, like on the file passed to extraFiles?

[SigmaSquadron]

Removed instances of with lib; per review in #324693.

[SigmaSquadron]

I had some time, so I added more options to configure oxenstored.conf. The options haven't changed in a decade, so I think it's alright to skip building a new config generator for oxenstored.conf's custom syntax, and just use etc."xen/oxenstored.conf".text.

xl's next, but that's a major undertaking which is best left for a separate PR.

[SigmaSquadron]

I notice that the module has gone through nixfmt; would you be able to reformat it in a separate commit before your substantive changes so that it’s easier to review exactly what changed, or do you think it has been sufficiently rewritten that comparing against the old state doesn’t even make sense?

I formatted the old version in a separate commit as requested. That said, the diff is still really hard to read because many options were moved around and config entries were deduplicated/nested, so I'd recommend looking at the full file instead of just the diff.

[emilazy]

This looks broadly good to me. I don’t know much about Xen, so my review here is mostly human linting and asking about things that stood out to me, but this shouldn’t interfere with setups that don’t use Xen and seems to be better quality code than what it’s replacing, which is good enough for me. A few things I’d like to see changed, but I’m deferring to @CertainLach’s approval as far as Xen matters go.

[emilazy]

If the C implementation is legacy and adds complexity to the implementation here, should we only support the OCaml one? Is there anything the OCaml one can’t do that the C one can?

[SigmaSquadron]

We can't, unfortunately. oxenstored does not support untrusted device domains, which is the main reason why Qubes OS (#341215) doesn't use it.

[emilazy]

Are these sufficiently bad configurations that we want them to be assertions, rather than warnings? (I’m perfectly fine with ruling out footguns like this; just want to check.)

[SigmaSquadron]

The quota stuff should certainly be kept, otherwise users might unknowingly open themselves to a known security vulnerability. The tracing stuff is more of a footgun, but could be replaced with a lib.warn with no issues. I don't see why someone would want to debug Xen without logs though.

[SigmaSquadron]

Changes addressed, except for the removal of the footgun assertions.

[emilazy]

Looks good to me! Any further improvements can be handled in future PRs. Thanks for all the work you’ve put into this.

@ofborg test simple

(just to make sure that NixOS eval is okay)

[SigmaSquadron]

The simple test has passed!

[SigmaSquadron]

A sincere thank you to everyone who has helped in this Xen endeavour!

@CertainLach, @hehongbo, @digitalrayne, @radhus and @matdibu, I've sent everyone who has been involved in these Xen PRs an email which may be of interest to you. Let me know what you think!

(If you haven't received it, then I did a terrible job finding your address. Please do tell me if that's the case.)