- Spectrum Development - spectrum-os.org

[PATCH] Add interrupt remapping support
by Demi Marie Obenour 30 May '25

30 May '25

This adds interrupt remapping to the virtio-IOMMU device. This is needed to support deprivileged userspace drivers on x86_64 and other platforms where interrupt remapping is the job of the IOMMU. It is not needed on AArch64 and must not be supported on that platform. --- device-types/iommu/description.tex | 70 +++++++++++++++++++++++++++++- 1 file changed, 69 insertions(+), 1 deletion(-) diff --git a/device-types/iommu/description.tex b/device-types/iommu/description.tex index f8cbe88..0a3bcab 100644 --- a/device-types/iommu/description.tex +++ b/device-types/iommu/description.tex @@ -3,7 +3,8 @@ \section{IOMMU device}\label{sec:Device Types / IOMMU Device} The virtio-iommu device manages Direct Memory Access (DMA) from one or more endpoints. It may act both as a proxy for physical IOMMUs managing devices assigned to the guest, and as virtual IOMMU managing emulated and -paravirtualized devices. +paravirtualized devices. On some platforms, it is also responsible for +interrupt remapping. The driver first discovers endpoints managed by the virtio-iommu device using platform specific mechanisms. It then sends requests to create @@ -74,6 +75,13 @@ \subsection{Feature bits}\label{sec:Device Types / IOMMU Device / Feature bits} whether endpoints that are attached to a domain are in bypass mode. +\item[VIRTIO_IOMMU_F_IRQ_MAP_UNMAP (7)] + Interrupt remapping is available. This is architecture specific + and MUST NOT be negotiated on architectures such as AArch64 where + interrupt remapping is not handled by the IOMMU. If this feature + is negotiated, all interrupts from endpoints that are not in + bypass mode are initially disabled. + \end{description} \drivernormative{\subsubsection}{Feature bits}{Device Types / IOMMU Device / Feature bits} @@ -531,6 +539,66 @@ \subsubsection{MAP request}\label{sec:Device Types / IOMMU Device / Device opera range mapped with VIRTIO_IOMMU_MAP_F_WRITE but not VIRTIO_IOMMU_MAP_F_READ. +\subsubsection{IRQ MAP request}\label{sec:Device Types / IOMMU Device / Device operations / IRQ MAP request} + +\begin{lstlisting} +struct virtio_iommu_req_irq_map { + struct virtio_iommu_req_head head; + le32 domain; + le64 msi_address; + le32 msi_payload; + le32 vector_id; + le32 vcpu_id; + le32 flags; + u8 reserved[4]; + struct virtio_iommu_req_tail tail; +}; +\end{lstlisting} + +Map a host MSI to a guest MSI directed at the given vCPU. vCPUs range from 0 to +$2^{32} - 2$ inclusive. $2^{32} - 1$ is reserved and means ``no vCPU'', +effectively disabling the interrupt. Any previous mapping of the MSI is overwritten. + +This request takes effect immediately. It is the device's job to flush caches if +necessary. However, any interrupts that are pending remain pending. + +The set of permitted values for \field{msi_address} and \field{msi_payload} +is architecture-dependent. Invalid values include, but are not limited to: + +\begin{itemize} +\item Values that are not in the architecture-dependent range of MSI addresses. +\item Values that have bits set that are ignored by the physical IOMMU. +\item Values that have reserved bits set. +\item Values that would cause the MSI to not be subject to interrupt remapping, + and which the host must therefore block for its own security. +\end{itemize} + +This request is only available when VIRTIO_IOMMU_F_IRQ_MAP_UNMAP has been negotiated. + +\drivernormative{\paragraph}{IRQ MAP request}{Device Types / IOMMU Device / Device operations / IRQ MAP request} + +The driver SHOULD set undefined \field{flags} bits to zero. + +The driver SHOULD NOT send IRQ MAP requests on a bypass domain. + +The driver SHOULD NOT choose values for \field{msi_address} or \field{msi_payload} +that are invalid for the CPU architecture. + +The driver SHOULD NOT choose a \field{vcpu_id} that corresponds to a vCPU that does +not exist and is not $2^{32} - 1$. + +\devicenormative{\paragraph}{IRQ MAP request}{Device Types / IOMMU Device / Device operations / IRQ MAP request} + +If \field{msi_address} or \field{msi_payload} is invalid for the CPU architecture, +the device SHOULD reject the request and set \field{status} to VIRTIO_IOMMU_S_INVAL. + +If \field{domain} does not exist, the device SHOULD reject the request and +set \field{status} to VIRTIO_IOMMU_S_NOENT. + +If \field{vcpu_id} does not correspond to a CPU that is running in the guest +and is not $2^{32} - 1$, the device SHOULD reject the request and set +\field{status} to VIRTIO_IOMMU_S_NOENT. + \subsubsection{UNMAP request}\label{sec:Device Types / IOMMU Device / Device operations / UNMAP request} \begin{lstlisting} -- Sincerely, Demi Marie Obenour

1 0

This Week in Spectrum, 2025-W21
by Alyssa Ross 25 May '25

25 May '25

Not too much to report this week. I spent most of the week either continuing with my recovery (this was a substantial fraction), or continuing work on future funding — hopefully I'll have good news to share about this at some point. I did update Cloud Hypervisor in Nixpkgs and release new a version of Spectrum's virtio-gpu patches for it. The good news is I'm now basically fully recovered, so should be back to normal from here on, once I've finished getting through the backlog of email. Until next week!

1 0

This Week in Spectrum, 2025-W20
by Alyssa Ross 18 May '25

18 May '25

I'm still recovering, and it's rough. There are some small signs of progress but it's a bit two steps forward, one step back. But here's what I managed to do this week in spite of things: • Updated[1] the binary cache builder scripts for Scaleway's block storage API migration. (The old one no longer works.) • Finished the networking test[2] I mentioned a couple of updates ago. • Deployed Anubis[3] on https://spectrum-os.org/git/ to stop the server being overloaded by AI scrapers. I'm unhappy it's come to this, but it made me feel better to realise it only activates on things that look like graphical web browsers, so curl, lynx, etc. still get through fine. • Dropped the hack[4] Spectrum had for loading device trees on aarch64 where they were spread across more than a dozen UKI extensions, thanks to systemd having dropped the limit of how many each UKI could include after I brought it up[5]. • Tested and merged a crosvm update in Nixpkgs[6]. • Finished some work to support encrypted user data partitions. This was a big blocker preventing Spectrum being really useful for anything. Currently, partitions have to be manually mounted on the command line, but I could imagine there being a nice GUI for this that runs on boot, a bit like what Tails has, since the OS itself doesn't have to be encrypted. • Discovered that the main blocker I knew about for building Spectrum for RISC-V had been resolved, so did some very early work for having Nixpkgs support RISC-V musl builds[7][8][9]. This one was a bit of a happy accident of my surgery recovery — I only tried it again on a lark because I wasn't well enough at the time to do anything else, and then made the happy discovery. Probably won't pursue this any more for a while, because apart from anything else obtaining RISC-V hardware at the moment isn't easy, but it's nice to know it's now theoretically possible. • Demi Marie Obenour helped me figure out that passthrough of Wi-Fi devices to VMs was not broken for complicated reasons to do with Cloud Hypervisor's VFIO implementation like I thought, but for simpler reasons: passthrough to a Fedora VM works, so it must just be some sort of misconfiguration in the Spectrum VM that should be relatively straightforward to narrow down and fix. I had tried to test passthrough to other guest OSes before, but since then I discovered that my main laptop has a faulty Wi-Fi card, so I suspect that produced confusing results that made me think it was something more complicated. • Continued work on arranging future funding for Spectrum. [1]: https://spectrum-os.org/git/infra/commit/?id=df2824a8e19c16a27adb951f664a53… [2]: https://spectrum-os.org/git/spectrum/tree/release/checks/networking?id=879b… [3]: https://anubis.techaro.lol/ [4]: https://spectrum-os.org/git/spectrum/commit/?id=e06b57f4fefc834f4868540a53d… [5]: https://github.com/systemd/systemd/commit/8c5b359579b0f1029edafb0bd96b5ebfb… [6]: https://github.com/NixOS/nixpkgs/pull/408305 [7]: https://github.com/NixOS/nixpkgs/pull/406797 [8]: https://github.com/NixOS/nixpkgs/pull/406966 [9]: https://github.com/NixOS/nixpkgs/pull/406996 Looking back at that list now, I'm pretty happy! Even though I was struggling for a lot of the week that's not too bad overall. Maybe I'm even happy enough with it that I feel justified including this bit again for the first time since the surgery: As a reminder, you can support my work by donating to Spectrum's development through GitHub Sponsors[10] or Liberapay[11]. This helps a lot, especially with ongoing maintenance (usually fixing upstream bugs etc.) that is difficult to fund via a grant. [10]: https://github.com/sponsors/alyssais/ [11]: https://liberapay.com/qyliss Until next week!

1 0

This Week in Spectrum, 2025-W19
by Alyssa Ross 11 May '25

11 May '25

Sadly this week has mostly been a continuation of the last — I'm still recovering from dental surgery. I spent the early part of the week in too much pain to think about much else, and the later part of the week in less pain but now struggling with side effects from painkillers. From what I understand there's not anything to worry about, but I've hit some bad luck and ended up with much worse and longer lasting pain than would usually be expected from this. So this isn't going to be the type of comprehensive report I'd like to be sending out every week, but I'll list some things I have been able to get done in those moments where I've been able to focus. • Updated Spectrum's pinned Nixpkgs and made some small improvements (mostly not committed yet) as a result of improvements in updated packages. • Got the automated test I was working on to the point where it's actually testing something useful — that networking works. Still want to polish it a bit more when I can focus better before I commit it. • Made a release of the Cloud Hypervisor virtio-gpu patches[1]. • Some long overdue work on the server that among other things hosts the Spectrum website, git repos, etc. • Reported a GTK regression that has made testing Spectrum very annoying for the last few months[2]. • Tested a crosvm update in Nixpkgs. • Worked on arranging continuing funding for Spectrum. [1]: https://spectrum-os.org/lists/archives/spectrum-discuss/877c2owzjl.fsf@alys… [2]: https://gitlab.gnome.org/GNOME/gtk/-/issues/7544 Most of this stuff has been in the last 2-3 days, so hopefully I'm on a good trajectory, but I don't know how long it's going to be before I'm back to normal.

1 0

This Week in Spectrum, 2025-W18
by Alyssa Ross 04 May '25

04 May '25

This week started off well — I was continuing working on the automated test I mentioned last week — but then I had two wisdom teeth removed and recovery has been hellish. So not much to report. I've fixed a couple of Nixpkgs things where I could but mostly I've been out of action. The other two are going to need to be removed sometime in the near future too… But hey, at least I've achieved my goal of a concise update!

1 0

This Week in Spectrum, 2025-W17
by Alyssa Ross 27 Apr '25

27 Apr '25

Apparently the last time I wrote an update like this was 2021-08-22[1]. Recently I've been missing them a lot, because I don't think it's ever been as easy to keep up with the progress being made as when I wrote weekly updates. Hopefully this time I can avoid going into quite the same level of detail, so they're more sustainable to keep writing. [1]: https://spectrum-os.org/lists/archives/spectrum-discuss/20210822213036.6lx5… So, here's what I did this week: Automated testing ----------------- For a long time I've had a branch on my computer that makes some significant changes to how networking in Spectrum works to try to resolve a longstanding race condition when starting VMs. I've found it difficult to work on, because it's hard for me to be confident when changing things around that I'm not going to subtly break something in a different way. It's been clear to me for a long time that the obvious answer to this is automated tests, but how they should work was a lot less clear. I'd like to avoid having to make a special testable version of the system, because I want to be testing the real thing. The aarch64 port I completed early this year has helped make the system just a bit more flexible, and a couple of weeks ago it clicked for me that perhaps it's time to make a serious attempt at this. So far, I have a program that starts Spectrum in QEMU. This is an unmodified Spectrum image, but the test uses systemd-stub's support for appending to the kernel command line via through SMBIOS Type 11 strings[2] to configure an extra serial console, which it then communicates with over a socket. Because this console was configured on the kernel command line, it has kernel logs printed to it, which could make trying to read command output from it messy. To work around that, the only interaction the test has with this console is to write a command into it to start a shell on a second serial console that isn't a destination for kernel logs, and then further interaction happens via that second console. (I tried lowering the kernel loglevel, but it seems some messages come through even when it's set to zero.) The test program then uses the Spectrum host shell to mount a filesystem on an attached disk image containing a custom VM configuration, import that VM, and run it. The VM just runs netcat to try to connect a server running on the host via the test program. If the host receives that connection, the test will pass, and once I have that working I can expand the test to make sure that it keeps working after restarting the different VMs involved. What's still to do is getting that server bit right — originally I planned to use QEMU's guestfwd[3] feature to forward connections to a specific IP address and port to an AF_UNIX socket, but that been broken for a long time[4], so instead I'll just use an AF_INET socket on the host. Since it has to be a non-loopback address, I also want the test to run itself in a network namespace so I'm not interfering with networking on the machine running it. Nothing that should be especially difficult. An early experiment with this led me to discover that Python's built-in socket library didn't expose the IP_FREEBIND socket option, so I sent a quick PR to do that[5], which was merged. [2]: https://www.freedesktop.org/software/systemd/man/latest/systemd-stub.html#S… [3]: https://www.qemu.org/docs/master/system/invocation.html#hxtool-5 [4]: https://gitlab.com/qemu-project/qemu/-/issues/1835 [5]: https://github.com/python/cpython/pull/132998 User-mode networking for development ------------------------------------ When developing the built-in Spectrum VMs, I run them directly on my NixOS development system. For the router VM in particular, it's important to test that it still connects to the network. Until now, that's only been possible with QEMU, which has built-in slirp-based user-mode networking — other VMMs would require privileged operations on the development system to have working networking, and it's important to me that the Spectrum development environment does not require special privileges. While I was working on the test and investigating QEMU's guestfwd feature, I discovered that there's a new option for user-mode networking: passt[6][7]. passt runs outside the VMM process, and implements a vhost-user interface, meaning that it should be possible to use from any VMM. I've changed the Spectrum development environment to use it when running VMs in Cloud Hypervisor[8], and also to run the router VM in Cloud Hypervisor by default[9], which means it's now easier to test that VM during development in an environment much more similar to the one it will ultimately run in as part of the Spectrum system. I also tried using passt with crosvm, but it didn't work due to crosvm's slightly strange interpretation of the vhost-user protocol. I sent a couple of patches[10][11] to crosvm to fix the incompatibility, which haven't been accepted yet but have prompted things to move in the right direction. I also sent a patch to passt itself to make it easier to use with an inetd/UCSPI-style super-server like s6-ipcserver, but a day later it still hasn't appeared in their list archive so I think it's probably waiting for somebody to find it in the list spam filter. [6]: https://passt.top/ [7]: https://www.qemu.org/docs/master/system/devices/net.html#using-passt-as-the… [8]: https://spectrum-os.org/git/spectrum/commit/?id=aac74f6165740a6b041a7205ec8… [9]: https://spectrum-os.org/git/spectrum/commit/?id=ca10038c080f396a6cf2649b726… [10]: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6491650 [11]: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6491651 Nixpkgs ------- I contributed a few fixes for build regressions that would get in the way of updating Spectrum's pinned Nixpkgs[12][13][14], and I also added debug symbols to the passt package[15]. [12]: https://github.com/NixOS/nixpkgs/pull/401563 [13]: https://github.com/NixOS/nixpkgs/pull/402027 [14]: https://github.com/NixOS/nixpkgs/pull/402055 [15]: https://github.com/NixOS/nixpkgs/pull/401971 That's it for this week. I'm at just over a thousand words, which is more than I was aiming for but better than I remember a lot of the past weekly updates being. Hopefully I'll be back with another update next week. As a reminder, you can support my work by donating to Spectrum's development through GitHub Sponsors[16] or Liberapay[17]. This helps a lot, especially with ongoing maintenance (usually fixing upstream bugs etc.) that is difficult to fund via a grant. [16]: https://github.com/sponsors/alyssais/ [17]: https://liberapay.com/qyliss

1 0

[PATCH www] Fix typo
by Jay Langford 24 Apr '25

24 Apr '25

Signed-off-by: Jay Langford <jay(a)jaylangford.net> --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 9a7d02e..cb96838 100644 --- a/index.html +++ b/index.html @@ -38,7 +38,7 @@ machines. <p> Spectrum is an upstream-first project. Wherever possible, we aim to participate in cross-project collaboration to move the entire free -desktop ecosystem forward, rather than desgining Spectrum-specific +desktop ecosystem forward, rather than designing Spectrum-specific solutions. This reduces the amount of software that Spectrum as a small project is solely responsible for maintaining, and it derisks the project — even if Spectrum does not achieve all its goals, our -- 2.39.3 (Apple Git-145)

2 2

[PATCH v3] img/app: add dejavu_fonts pkg and fontconfig file
by Samy Lahfa 01 Mar '25

01 Mar '25

Spam detection software, running on the system "atuin.qyliss.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Signed-off-by: Samy Lahfa <samy%2Bspectrum(a)lahfa.xyz> This fixes the foot terminal app-vm by adding dejavu_fonts package to the nix store as well as adding the fontconfig file, so it knows which default font to use. --- img/app/Makefile | 2 ++ img/app/de [...] Content analysis details: (5.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: lahfa.xyz (xyz)] 2.0 FROM_SUSPICIOUS_NTLD_FP From abused NTLD 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS -0.0 DMARC_PASS DMARC pass policy

3 2

[PATCH v2] img/app: add dejavu_fonts pkg and fontconfig file
by Samy Lahfa 20 Feb '25

20 Feb '25

Signed-off-by: Samy Lahfa <samy%2Bspectrum(a)lahfa.xyz> --- This fixes the foot terminal app-vm by adding dejavu_fonts package to the nix store as well as adding the fontconfig file, so it knows which default font to use. img/app/Makefile | 2 ++ img/app/default.nix | 3 ++- img/app/etc/fonts/fonts.conf | 21 +++++++++++++++++++++ 3 files changed, 25 insertions(+), 1 deletion(-) create mode 100644 img/app/etc/fonts/fonts.conf diff --git a/img/app/Makefile b/img/app/Makefile index 7887aa8..eeb17fa 100644 --- a/img/app/Makefile +++ b/img/app/Makefile @@ -30,6 +30,7 @@ $(imgdir)/appvm/blk/root.img: ../../scripts/make-gpt.sh ../../scripts/sfdisk-fie VM_FILES = \ etc/dbus-1/session.conf \ + etc/fonts/fonts.conf \ etc/fstab \ etc/init \ etc/mdev.conf \ @@ -52,6 +53,7 @@ VM_FILES = \ etc/s6-linux-init/scripts/rc.shutdown \ etc/s6-linux-init/scripts/rc.shutdown.final \ etc/xdg/xdg-desktop-portal/portals.conf + VM_DIRS = dev run proc sys tmp \ etc/s6-linux-init/run-image/service VM_FIFOS = etc/s6-linux-init/run-image/service/s6-linux-init-shutdownd/fifo diff --git a/img/app/default.nix b/img/app/default.nix index 6537fb2..5b58a5f 100644 --- a/img/app/default.nix +++ b/img/app/default.nix @@ -8,7 +8,7 @@ pkgsStatic.callPackage ( { lib, stdenvNoCC, runCommand, writeClosure , erofs-utils, jq, s6-rc, util-linux , busybox, cacert, execline, kmod, linux_latest, mdevd, s6, s6-linux-init -, xdg-desktop-portal-spectrum +, xdg-desktop-portal-spectrum, dejavu_fonts, }: let @@ -37,6 +37,7 @@ let s6-rc terminfo xdg-desktop-portal-spectrum + dejavu_fonts # Some packages can't (currently?) be built statically. diff --git a/img/app/etc/fonts/fonts.conf b/img/app/etc/fonts/fonts.conf new file mode 100644 index 0000000..0dcde54 --- /dev/null +++ b/img/app/etc/fonts/fonts.conf @@ -0,0 +1,21 @@ +<?xml version="1.0" encoding="UTF-8"?> + + +<!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd"> +<fontconfig> + <alias binding="same"> + <family>monospace</family> + <prefer> + <family>DejaVu Sans Mono</family> + </prefer> + </alias> + + <alias binding="same"> + <family>sans-serif</family> + <prefer> + <family>DejaVu Sans</family> + </prefer> + </alias> + + <dir>/usr/share/fonts</dir> +</fontconfig> -- 2.47.2

3 5

[PATCH] fix(foot-vm): add dejavu_fonts and fontconfig
by Samy Lahfa 30 Jan '25

30 Jan '25

Signed-off-by: Samy Lahfa <samy%2Bspectrum(a)lahfa.xyz> --- img/app/Makefile | 3 ++- img/app/default.nix | 1 + img/app/etc/fonts/fonts.conf | 21 +++++++++++++++++++++ 3 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 img/app/etc/fonts/fonts.conf diff --git a/img/app/Makefile b/img/app/Makefile index 7887aa8..8bfb7a1 100644 --- a/img/app/Makefile +++ b/img/app/Makefile @@ -51,7 +51,8 @@ VM_FILES = \ etc/s6-linux-init/scripts/rc.init \ etc/s6-linux-init/scripts/rc.shutdown \ etc/s6-linux-init/scripts/rc.shutdown.final \ - etc/xdg/xdg-desktop-portal/portals.conf + etc/xdg/xdg-desktop-portal/portals.conf \ + etc/fonts/fonts.conf VM_DIRS = dev run proc sys tmp \ etc/s6-linux-init/run-image/service VM_FIFOS = etc/s6-linux-init/run-image/service/s6-linux-init-shutdownd/fifo diff --git a/img/app/default.nix b/img/app/default.nix index 6537fb2..fc2af0e 100644 --- a/img/app/default.nix +++ b/img/app/default.nix @@ -37,6 +37,7 @@ let s6-rc terminfo xdg-desktop-portal-spectrum + pkgs.dejavu_fonts # Some packages can't (currently?) be built statically. diff --git a/img/app/etc/fonts/fonts.conf b/img/app/etc/fonts/fonts.conf new file mode 100644 index 0000000..0dcde54 --- /dev/null +++ b/img/app/etc/fonts/fonts.conf @@ -0,0 +1,21 @@ +<?xml version="1.0" encoding="UTF-8"?> + + +<!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd"> +<fontconfig> + <alias binding="same"> + <family>monospace</family> + <prefer> + <family>DejaVu Sans Mono</family> + </prefer> + </alias> + + <alias binding="same"> + <family>sans-serif</family> + <prefer> + <family>DejaVu Sans</family> + </prefer> + </alias> + + <dir>/usr/share/fonts</dir> +</fontconfig> -- 2.47.2

3 2