- Spectrum Development - spectrum-os.org

I'll be on holiday for two weeks
by Alyssa Ross 30 Sep '22

30 Sep '22

I'm taking a holiday from my work for Unikie for two weeks starting now. (Back on Monday, 9th Oct.) I'll be spending some of the time finishing up some work for NLnet before Spectrum's grant expires, so you'll almost certainly still see some activity from me on the lists. But the rest of the time I'm going to try to spend away, relaxing, so anybody sending patches should not be alarmed if they go a couple of weeks before I take a look at them. :) Alyssa

1 1

[RFC PATCH nixpkgs 0/4] Wayland security-context support
by Puck Meerburg 30 Sep '22

30 Sep '22

NOTE: These patches are designed to apply on top of the previous Wayland support series at [1]. This series contains the patches necessary to build the demo repository for Wayland security-context[2] support. As the Spectrum support for Wayland is also very WIP, and uses a different WM than the one I was focused on (Weston versus sway), it's not yet integrated with Spectrum itself. Of course, my decision to use Sway in this demo isn't setting Spectrum's own window manager in stone; the hope is this protocol gets implemented into as many compositors (and sandboxes) as possible :) To try out the demo, see [3] for the repository and instructions. A few of these patches (wlroots, sway) have been sent upstream already[4][5]. The crosvm patches need a tiny bit of work before I'm completely confident sending them upstream. One major issue that is worked around but not entirely solved is a bit of a mystery to me: After a short amount of messages, the virtio-gpu driver stops sending and receiving Wayland messages. As far as I can tell, this is likely a quirk of running crosvm with only cross-domain enabled, but one I haven't been able to delve into the Linux source code for to figure out how to properly solve. [1]: https://spectrum-os.org/lists/archives/spectrum-devel/20220928170128.158379… [2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68 [3]: https://puck.moe/git/security-context-demo [4]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3589 [5]: https://github.com/swaywm/sway/pull/7187 Puck Meerburg (4): cloud-hypervisor: workaround keymap mmap wlroots: apply security-context patches sway: apply security-context patches crosvm: apply security-context patches ...ry-mapping-shared-memory-as-RO-if-RW.patch | 57 ++++++++ .../cloud-hypervisor/default.nix | 1 + .../virtualization/crosvm/default.nix | 10 +- .../window-managers/sway/default.nix | 22 +++ pkgs/development/libraries/wlroots/0.15.nix | 20 ++- .../libraries/wlroots/security-context-v1.xml | 131 ++++++++++++++++++ 6 files changed, 235 insertions(+), 6 deletions(-) create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0004-virtio-devices-try-mapping-shared-memory-as-RO-if-RW.patch create mode 100644 pkgs/development/libraries/wlroots/security-context-v1.xml -- 2.35.1

1 5

[RFC PATCH v2 00/10] Initial support for VM Wayland
by Alyssa Ross 30 Sep '22

30 Sep '22

IMPORTANT NOTE: this series should be applied on top of my previous series "Introduce a shared base for application VMs" [1]. This is a bit inconvenient I know, but I haven't committed the other series yet due to wanting to take a second pass at it. Changes since v1: - Fix syntax in img/app development Makefile target. - Enable virgl for virtio-gpu devices (see below). v1: https://spectrum-os.org/lists/archives/spectrum-devel/20220928170128.158379… Introduction ------------ This series adds the Spectrum-side support for running VMs that can display Wayland windows on the host compositor, using virtio-gpu. There are various small things still to be resolved, but it's ready for other people to try out and test. The easiest way to test this out is to run "vm-start hello-wayland" on the Spectrum host. If everything goes well, a small window with a picture of a cat (hello-wayland) should appear. This window is running in a VM. Currently, virgl is enabled for all virtio-gpu devices. This means that all VMs will have GPU acceleration enabled. This is currently required to work around what appears to be a kernel bug that causes applications to freeze, but is likely not something we want to be enabling by default once that's fixed. I have tested with hello-wayland, as in the appvm provided as a demonstration here, and also with foot (by replacing hello-wayland with foot in that VM). I haven't done enough testing with this version of the code to guage how reliably they work yet. [1]: https://spectrum-os.org/lists/archives/spectrum-devel/20220919073659.170327… [2]: https://spectrum-os.org/lists/archives/spectrum-devel/20220928170128.158379… Alyssa Ross (10): host/start-vm: use MAP_SHARED memory for VMs img/app: don't block app startup on network online img/app: add Wayland over virtio-gpu support to kernel vm-lib: add mesa drivers to VM img/app: add support for testing virtio-gpu img/app: add support for testing in crosvm host/start-vm: factor out VM definition path host: add support for Wayland in VMs vm/app: add hello-wayland demo VM host/start-vm: disable cloud-hypervisor sandbox Documentation/creating-vms.adoc | 5 +++ host/initramfs/extfs.nix | 3 ++ host/rootfs/Makefile | 4 +++ host/rootfs/default.nix | 4 +-- host/rootfs/etc/s6-rc/ext-rc-init/up | 8 +++++ host/rootfs/etc/template/gpu/data/check | 5 +++ host/rootfs/etc/template/gpu/notification-fd | 1 + .../etc/template/gpu/notification-fd.license | 2 ++ host/rootfs/etc/template/gpu/run | 9 ++++++ host/rootfs/etc/template/gpu/type | 1 + host/rootfs/etc/template/gpu/type.license | 2 ++ host/start-vm/start-vm.rs | 26 +++++++++------ img/app/Makefile | 32 +++++++++++++++++-- img/app/default.nix | 3 +- img/app/etc/mdev/iface | 2 +- img/app/etc/mdev/listen | 12 +++++++ img/app/etc/mdev/wait | 15 +++++++++ img/app/etc/s6-rc/ok-all/contents | 1 + img/app/shell.nix | 2 +- vm-lib/make-vm.nix | 14 ++++++-- vm/app/catgirl.nix | 1 + vm/app/hello-wayland.nix | 25 +++++++++++++++ vm/app/lynx.nix | 1 + 23 files changed, 159 insertions(+), 19 deletions(-) create mode 100755 host/rootfs/etc/template/gpu/data/check create mode 100644 host/rootfs/etc/template/gpu/notification-fd create mode 100644 host/rootfs/etc/template/gpu/notification-fd.license create mode 100755 host/rootfs/etc/template/gpu/run create mode 100644 host/rootfs/etc/template/gpu/type create mode 100644 host/rootfs/etc/template/gpu/type.license create mode 100755 img/app/etc/mdev/listen create mode 100755 img/app/etc/mdev/wait create mode 100644 vm/app/hello-wayland.nix -- 2.37.1

1 11

[RFC PATCH nixpkgs v2 0/9] virtio-gpu with crosvm and cloud-hypervisor
by Alyssa Ross 30 Sep '22

30 Sep '22

Changes since v1 ---------------- - Fixed the cloud-hypervisor seccomp sandbox for the GPU device. - Worked around crosvm not handling wlroots's read-only keymaps in cloud-hypervisor. (Thanks Puck.) - Switched to cherry-picks of sternenseemann's ocamlPackages.wayland and wayland-proxy-virtwl updates from upstream. v1: https://spectrum-os.org/lists/archives/spectrum-devel/20220928170128.158379… Introduction ------------ This series contains all the changes needed to make it possible to run Wayland over cross-domain virtio-gpu using cloud-hypervisor. It only contains changes needed to packages in Nixpkgs, so there's no Spectrum integration here. That's a separate patchset, of which I'll also be sending v2 soon. There's also still some work to do here, hence being marked RFC — in the cloud-hypervisor patch you'll spot a few TODOs and FIXMEs — but it's ready for other people to have a look at and test. With these changes, it's possible to run a cloud-hypervisor VM with a GPU attached as follows: crosvm device gpu --socket vhost-user-gpu.sock ... cloud-hypervisor --gpu socket=vhost-user-gpu.sock ... Then in the guest, just run a Wayland application under wayland-proxy-virtwl: wayland-proxy-virtwl --virtio-gpu hello-wayland For Wayland over cross-domain virtio-gpu, which we're particularly interested in, the full crosvm command line would be something like: crosvm device gpu --socket vhost-user-gpu.sock \ --wayland-sock "$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" \ --params '{"context-types": "virgl:virgl2:cross-domain"}' Overview -------- We start by upgrading crosvm to a beta version (since very recent changes changed their vhost-user implementation in a way that makes it significantly easier to interoperate with from cloud-hypervisor), then applying a few small fixes for cases where crosvm had made assumptions that were violated by cloud-hypervisor. Next, we apply patches to cloud-hypervisor and some of its dependencies, to implement the frontend of the GPU device. Finally, we upgrade wayland-proxy-virtwl (the program that speaks virtio-gpu and acts as the Wayland compositor inside the guest) to a version that supports virtio-gpu. I'm using wayland-proxy-virtwl over Sommelier here primary because Sommelier appears to have broken with Linux 5.19, but another nice benefit is that wayland-proxy-virtwl is maintained by somebody that we know and talk to sometimes on discuss(a)spectrum-os.org. Upstreamability --------------- A question anybody looking at the volume of changes here should be asking is: "To what extent is this upstreamable?". It's a bit of a mixed bag — most notably, cloud-hypervisor is not interested in virtio-gpu[1], so we'll have to maintain the cloud-hypervisor patches ourselves until we can come up with a more upstream-friendly solution (e.g. a vfio-user implementation of virtio-gpu). We also can't upstream the changes to the vhost crate, as the protocol we are using is crosvm specific, and so some standardisation work would need to happen there. But we can upstream the changes to crosvm, and the virtio-bindings crate. I've already started on the latter. As for the patches to Nixpkgs itself here, the updates to wayland-proxy-virtwl and the wayland library it depends on are already upstream (thanks sterni), I have an open PR[2] for the crosvm update (although to 105.0 rather than 106.3 than here, since the 106 series is still in beta), and the rustPlatform change is also upstreamable, but would require auditing Nixpkgs for cargoSha256 values that would change as a result. [1]: https://github.com/cloud-hypervisor/cloud-hypervisor/discussions/3960#discu… [2]: https://github.com/NixOS/nixpkgs/pull/193746 Alyssa Ross (7): crosvm: switch back to old git repo URL crosvm.updateScript: update release branch format crosvm: 104.0 -> 106.2 crosvm.updateScript: don't vendor Cargo.lock crosvm: add fixes for cloud-hypervisor virtio-gpu rustPlatform: forward unpack hooks to cargo fetch cloud-hypervisor: add virtio-gpu support sternenseemann (2): ocamlPackages.wayland: 1.0 -> 1.1 wayland-proxy-virtwl: unstable-2021-12-05 -> unstable-2022-09-22 .../0001-build-use-local-vhost.patch | 39 + ...dings-regenerate-with-bindgen-0.60.1.patch | 2589 ++++++++++++ ...0002-build-use-local-virtio-bindings.patch | 39 + ...gs-remove-workaround-for-old-bindgen.patch | 28 + ...-bindings-regenerate-with-Glibc-2.36.patch | 247 ++ ...0003-virtio-devices-add-a-GPU-device.patch | 1279 ++++++ ...-bindings-regenerate-with-Linux-5.19.patch | 1067 +++++ ...tio-bindings-add-virtio-gpu-bindings.patch | 3587 +++++++++++++++++ .../cloud-hypervisor/default.nix | 64 +- ...ser-add-shared-memory-region-support.patch | 724 ++++ .../virtualization/crosvm/Cargo.lock | 2214 ---------- .../crosvm/default-seccomp-policy-dir.diff | 38 +- .../virtualization/crosvm/default.nix | 15 +- ...-consider-shm-buuffers-when-setting-.patch | 34 + ...t_user-loosen-expected-message-order.patch | 71 + ...ces-vhost_user-remove-spurious-check.patch | 42 + .../virtualization/crosvm/update.py | 15 +- .../rust/build-rust-package/default.nix | 4 +- .../ocaml-modules/wayland/default.nix | 8 +- .../wayland/wayland-proxy-virtwl/default.nix | 17 +- 20 files changed, 9857 insertions(+), 2264 deletions(-) create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0001-build-use-local-vhost.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0001-virtio-bindings-regenerate-with-bindgen-0.60.1.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0002-build-use-local-virtio-bindings.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0002-virtio-bindings-remove-workaround-for-old-bindgen.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0003-virtio-bindings-regenerate-with-Glibc-2.36.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0003-virtio-devices-add-a-GPU-device.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0004-virtio-bindings-regenerate-with-Linux-5.19.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0005-virtio-bindings-add-virtio-gpu-bindings.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/vhost-vhost_user-add-shared-memory-region-support.patch delete mode 100644 pkgs/applications/virtualization/crosvm/Cargo.lock create mode 100644 pkgs/applications/virtualization/crosvm/devices-properly-consider-shm-buuffers-when-setting-.patch create mode 100644 pkgs/applications/virtualization/crosvm/devices-vhost_user-loosen-expected-message-order.patch create mode 100644 pkgs/applications/virtualization/crosvm/devices-vhost_user-remove-spurious-check.patch base-commit: 768879638cfd6a54664b762ec98a7f8f45620c44 -- 2.37.1

1 9

[RFC PATCH 00/10] Initial support for VM Wayland
by Alyssa Ross 30 Sep '22

30 Sep '22

IMPORTANT NOTE: this series should be applied on top of my previous series "Introduce a shared base for application VMs" [1]. This is a bit inconvenient I know, but I haven't committed the other series yet due to wanting to take a second pass at it. This series adds the Spectrum-side support for running VMs that can display Wayland windows on the host compositor, using virtio-gpu. There are various small things still to be resolved, but it's ready for other people to try out and test. The easiest way to test this out is to run "vm-start hello-wayland" on the Spectrum host. If everything goes well, a small window with a picture of a cat (hello-wayland) should appear. This window is running in a VM. One particular known issue is that on one run of the new appvm-hello-wayland, I got this error: [12:11:52.107] libwayland: error in client communication (pid 863) I'm not yet aware of what would cause such an error. It went away after I rebooted and tried again. There are some other known issues with my cloud-hypervisor patch too. See the other thread for information on those. [1]: https://spectrum-os.org/lists/archives/spectrum-devel/20220919073659.170327… [2]: https://spectrum-os.org/lists/archives/spectrum-devel/20220928170128.158379… Alyssa Ross (10): host/start-vm: use MAP_SHARED memory for VMs img/app: don't block app startup on network online img/app: add Wayland over virtio-gpu support to kernel vm-lib: add mesa drivers to VM img/app: add support for testing virtio-gpu img/app: add support for testing in crosvm host/start-vm: factor out VM definition path host: add support for Wayland in VMs vm/app: add hello-wayland demo VM host/start-vm: disable cloud-hypervisor sandbox Documentation/creating-vms.adoc | 5 +++ host/initramfs/extfs.nix | 3 ++ host/rootfs/Makefile | 4 +++ host/rootfs/default.nix | 4 +-- host/rootfs/etc/s6-rc/ext-rc-init/up | 8 +++++ host/rootfs/etc/template/gpu/data/check | 5 +++ host/rootfs/etc/template/gpu/notification-fd | 1 + .../etc/template/gpu/notification-fd.license | 2 ++ host/rootfs/etc/template/gpu/run | 9 ++++++ host/rootfs/etc/template/gpu/type | 1 + host/rootfs/etc/template/gpu/type.license | 2 ++ host/start-vm/start-vm.rs | 26 +++++++++------ img/app/Makefile | 32 +++++++++++++++++-- img/app/default.nix | 3 +- img/app/etc/mdev/iface | 2 +- img/app/etc/mdev/listen | 12 +++++++ img/app/etc/mdev/wait | 15 +++++++++ img/app/etc/s6-rc/ok-all/contents | 1 + img/app/shell.nix | 2 +- vm-lib/make-vm.nix | 14 ++++++-- vm/app/catgirl.nix | 1 + vm/app/hello-wayland.nix | 25 +++++++++++++++ vm/app/lynx.nix | 1 + 23 files changed, 159 insertions(+), 19 deletions(-) create mode 100755 host/rootfs/etc/template/gpu/data/check create mode 100644 host/rootfs/etc/template/gpu/notification-fd create mode 100644 host/rootfs/etc/template/gpu/notification-fd.license create mode 100755 host/rootfs/etc/template/gpu/run create mode 100644 host/rootfs/etc/template/gpu/type create mode 100644 host/rootfs/etc/template/gpu/type.license create mode 100755 img/app/etc/mdev/listen create mode 100755 img/app/etc/mdev/wait create mode 100644 vm/app/hello-wayland.nix -- 2.37.1

1 11

[PATCH v2] EFI Loader: use correct arch suffix
by Ivan Nikolaenko 29 Sep '22

29 Sep '22

Previously there were hardcoded "x64" in EFI loaders' filenames. Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko(a)unikie.com> --- img/combined/default.nix | 8 +++++--- img/live/Makefile | 2 +- img/live/default.nix | 6 ++++-- 3 files changed, 10 insertions(+), 6 deletions(-) diff --git a/img/combined/default.nix b/img/combined/default.nix index 3989d55..f65f619 100644 --- a/img/combined/default.nix +++ b/img/combined/default.nix @@ -6,7 +6,7 @@ let inherit (builtins) storeDir; - inherit (pkgs.lib) removePrefix; + inherit (pkgs.lib) removePrefix toUpper; eosimages = import ./eosimages.nix { inherit config; }; @@ -31,6 +31,8 @@ let --owner 0 --group 0 | tar2sqfs $out ''; + efiArch = stdenv.hostPlatform.efiArch; + grub = grub2_efi; grubCfg = substituteAll { @@ -74,8 +76,8 @@ let done mcopy -i $out ${grub}/share/grub/unicode.pf2 ::/grub/fonts - grub-mkimage -o grubx64.efi -p "(hd0,gpt1)/grub" -O ${grub.grubTarget} part_gpt fat - mcopy -i $out grubx64.efi ::/EFI/BOOT/BOOTX64.EFI + grub-mkimage -o grub${efiArch}.efi -p "(hd0,gpt1)/grub" -O ${grub.grubTarget} part_gpt fat + mcopy -i $out grub${efiArch}.efi ::/EFI/BOOT/BOOT${toUpper efiArch}.EFI fsck.vfat -n $out ''; diff --git a/img/live/Makefile b/img/live/Makefile index 9815c88..e63c598 100644 --- a/img/live/Makefile +++ b/img/live/Makefile @@ -36,7 +36,7 @@ build/boot.fat: $(KERNEL) $(INITRAMFS) $(SYSTEMD_BOOT_EFI) build/spectrum.conf $(MCOPY) -i $@ build/spectrum.conf ::/loader/entries $(MCOPY) -i $@ $(KERNEL) ::/spectrum/linux $(MCOPY) -i $@ $(INITRAMFS) ::/spectrum/initrd - $(MCOPY) -i $@ $(SYSTEMD_BOOT_EFI) ::/EFI/BOOT/BOOTX64.EFI + $(MCOPY) -i $@ $(SYSTEMD_BOOT_EFI) ::/EFI/BOOT/$(EFINAME) # veritysetup format produces two files, but Make only (portably) # supports one output per rule, so we combine the two outputs then diff --git a/img/live/default.nix b/img/live/default.nix index 1fa8da3..4301ccc 100644 --- a/img/live/default.nix +++ b/img/live/default.nix @@ -9,7 +9,7 @@ let inherit (config) pkgs; - inherit (pkgs.lib) cleanSource cleanSourceWith hasSuffix; + inherit (pkgs.lib) cleanSource cleanSourceWith hasSuffix toUpper; extfs = pkgs.pkgsStatic.callPackage ../../host/initramfs/extfs.nix { inherit config; @@ -17,6 +17,7 @@ let rootfs = import ../../host/rootfs { inherit config; }; scripts = import ../../scripts { inherit config; }; initramfs = import ../../host/initramfs { inherit config rootfs; }; + efiArch = stdenv.hostPlatform.efiArch; in stdenvNoCC.mkDerivation { @@ -35,7 +36,8 @@ stdenvNoCC.mkDerivation { INITRAMFS = initramfs; KERNEL = "${rootfs.kernel}/${stdenv.hostPlatform.linux-kernel.target}"; ROOT_FS = rootfs; - SYSTEMD_BOOT_EFI = "${systemd}/lib/systemd/boot/efi/systemd-bootx64.efi"; + SYSTEMD_BOOT_EFI = "${systemd}/lib/systemd/boot/efi/systemd-boot${efiArch}.efi"; + EFINAME = "BOOT${toUpper efiArch}.EFI"; buildFlags = [ "build/live.img" ]; makeFlags = [ "SCRIPTS=${scripts}" ]; -- 2.25.1

3 2

[RFC PATCH nixpkgs 0/9] virtio-gpu with crosvm and cloud-hypervisor
by Alyssa Ross 29 Sep '22

29 Sep '22

Introduction ------------ This series contains all the changes needed to make it possible to run Wayland over cross-domain virtio-gpu using cloud-hypervisor. It only contains changes needed to packages in Nixpkgs, so there's no Spectrum integration here. That'll be coming soon. There's also still some work to do here, hence being marked RFC — in the cloud-hypervisor patch you'll spot a few TODOs and FIXMEs — but it's ready for other people to have a look at and test. With these changes, it's possible to run a cloud-hypervisor VM with a GPU attached as follows: crosvm device gpu --socket vhost-user-gpu.sock ... cloud-hypervisor --gpu socket=vhost-user-gpu.sock ... Then in the guest, just run a Wayland application under wayland-proxy-virtwl: wayland-proxy-virtwl --virtio-gpu hello-wayland For Wayland over cross-domain virtio-gpu, which we're particularly interested in, the full crosvm command line would be something like: crosvm device gpu --socket vhost-user-gpu.sock \ --wayland-sock "$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" \ --params '{"context-types": "cross-domain"}' Overview -------- We start by upgrading crosvm to a beta version (since very recent changes changed their vhost-user implementation in a way that makes it significantly easier to interoperate with from cloud-hypervisor), then applying a few small fixes for cases where crosvm had made assumptions that were violated by cloud-hypervisor. Next, we apply patches to cloud-hypervisor and some of its dependencies, to implement the frontend of the GPU device. Finally, we upgrade wayland-proxy-virtwl (the program that speaks virtio-gpu and acts as the Wayland compositor inside the guest) to a version that supports virtio-gpu. I'm using wayland-proxy-virtwl over Sommelier here primary because Sommelier appears to have broken with Linux 5.19, but another nice benefit is that wayland-proxy-virtwl is maintained by somebody that we know and talk to sometimes on discuss(a)spectrum-os.org. Upstreamability --------------- A question anybody looking at the volume of changes here should be asking is: "To what extent is this upstreamable?". It's a bit of a mixed bag — most notably, cloud-hypervisor is not interested in virtio-gpu[1], so we'll have to maintain the cloud-hypervisor patches ourselves until we can come up with a more upstream-friendly solution (e.g. a vfio-user implementation of virtio-gpu). We also can't upstream the changes to the vhost crate, as the protocol we are using is crosvm specific, and so some standardisation work would need to happen there. But we can upstream the changes to crosvm, and the virtio-bindings crate. I've already started on the latter. As for the patches to Nixpkgs itself here, we can upstream the crosvm update (although should probably target 105 if I get round to it soon, since 106 is still beta), the rustPlatform change, and the updates to wayland-proxy-virtwl and the wayland library it depends on. [1]: https://github.com/cloud-hypervisor/cloud-hypervisor/discussions/3960#discu… Alyssa Ross (9): crosvm: switch back to old git repo URL crosvm.updateScript: update release branch format crosvm: 104.0 -> 106.2 crosvm.updateScript: don't vendor Cargo.lock crosvm: add fixes for cloud-hypervisor virtio-gpu rustPlatform: forward unpack hooks to cargo fetch cloud-hypervisor: add virtio-gpu support ocamlPackages.wayland: 1.0 -> unstable-2022-05-07 wayland-proxy-virtwl: unstable-2021-12-05 -> unstable-2022-08-06 .../0001-build-use-local-vhost.patch | 39 + ...dings-regenerate-with-bindgen-0.60.1.patch | 2589 ++++++++++++ ...0002-build-use-local-virtio-bindings.patch | 39 + ...gs-remove-workaround-for-old-bindgen.patch | 28 + ...-bindings-regenerate-with-Glibc-2.36.patch | 247 ++ ...-devices-add-a-vhost-user-gpu-device.patch | 1253 ++++++ ...-bindings-regenerate-with-Linux-5.19.patch | 1067 +++++ ...tio-bindings-add-virtio-gpu-bindings.patch | 3587 +++++++++++++++++ .../cloud-hypervisor/default.nix | 64 +- ...ser-add-shared-memory-region-support.patch | 724 ++++ .../virtualization/crosvm/Cargo.lock | 2214 ---------- .../crosvm/default-seccomp-policy-dir.diff | 38 +- .../virtualization/crosvm/default.nix | 15 +- ...-consider-shm-buuffers-when-setting-.patch | 34 + ...t_user-loosen-expected-message-order.patch | 71 + ...ces-vhost_user-remove-spurious-check.patch | 42 + .../virtualization/crosvm/update.py | 15 +- .../rust/build-rust-package/default.nix | 4 +- .../ocaml-modules/wayland/default.nix | 12 +- .../wayland/wayland-proxy-virtwl/default.nix | 14 +- 20 files changed, 9834 insertions(+), 2262 deletions(-) create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0001-build-use-local-vhost.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0001-virtio-bindings-regenerate-with-bindgen-0.60.1.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0002-build-use-local-virtio-bindings.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0002-virtio-bindings-remove-workaround-for-old-bindgen.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0003-virtio-bindings-regenerate-with-Glibc-2.36.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0003-virtio-devices-add-a-vhost-user-gpu-device.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0004-virtio-bindings-regenerate-with-Linux-5.19.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/0005-virtio-bindings-add-virtio-gpu-bindings.patch create mode 100644 pkgs/applications/virtualization/cloud-hypervisor/vhost-vhost_user-add-shared-memory-region-support.patch delete mode 100644 pkgs/applications/virtualization/crosvm/Cargo.lock create mode 100644 pkgs/applications/virtualization/crosvm/devices-properly-consider-shm-buuffers-when-setting-.patch create mode 100644 pkgs/applications/virtualization/crosvm/devices-vhost_user-loosen-expected-message-order.patch create mode 100644 pkgs/applications/virtualization/crosvm/devices-vhost_user-remove-spurious-check.patch base-commit: 768879638cfd6a54664b762ec98a7f8f45620c44 -- 2.37.1

2 13

[PATCH] scripts/make-gpt.sh: make GPT offset configurable
by Ivan Nikolaenko 29 Sep '22

29 Sep '22

These changes can be used in an external configuration layer as follows: overlays = [ (self: super: { gptOffset = 9437184; }) ]; Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko(a)unikie.com> --- This patch is not a solution but just a proposal about how things can be done. There is at least one another way of doing this (having our own make-gpt.sh script), but I thought that editing of the current one is better way. Also I don't know should we also consider other images and rootfs be fixed this way. img/live/Makefile | 3 ++- img/live/default.nix | 1 + scripts/make-gpt.sh | 22 ++++++++++++++++++++-- 3 files changed, 23 insertions(+), 3 deletions(-) diff --git a/img/live/Makefile b/img/live/Makefile index 9815c88..5a29156 100644 --- a/img/live/Makefile +++ b/img/live/Makefile @@ -19,7 +19,8 @@ build/live.img: $(SCRIPTS)/format-uuid.sh $(SCRIPTS)/make-gpt.sh build/boot.fat build/boot.fat:c12a7328-f81f-11d2-ba4b-00a0c93ec93b \ build/rootfs.verity.superblock:2c7357ed-ebd2-46d9-aec1-23d437ec2bf5:$$($(SCRIPTS)/format-uuid.sh "$$(dd if=build/rootfs.verity.roothash bs=32 skip=1 count=1 status=none)") \ $(ROOT_FS):4f68bce3-e8cd-4db1-96e7-fbcaf984b709:$$($(SCRIPTS)/format-uuid.sh "$$(head -c 32 build/rootfs.verity.roothash)") \ - $(EXT_FS):9293e1ff-cee4-4658-88be-898ec863944f + $(EXT_FS):9293e1ff-cee4-4658-88be-898ec863944f \ + --gptoffset=$(GPT_OFFSET) mv $@.tmp $@ build/spectrum.conf: build/rootfs.verity.roothash diff --git a/img/live/default.nix b/img/live/default.nix index 5461384..c529206 100644 --- a/img/live/default.nix +++ b/img/live/default.nix @@ -34,6 +34,7 @@ stdenvNoCC.mkDerivation { KERNEL = "${rootfs.kernel}/${stdenv.hostPlatform.linux-kernel.target}"; ROOT_FS = rootfs; SYSTEMD_BOOT_EFI = "${systemd}/lib/systemd/boot/efi/systemd-bootx64.efi"; + GPT_OFFSET=pkgs.gptOffset or null; buildFlags = [ "build/live.img" ]; makeFlags = [ "SCRIPTS=${scripts}" ]; diff --git a/scripts/make-gpt.sh b/scripts/make-gpt.sh index 56076d3..e8dd067 100755 --- a/scripts/make-gpt.sh +++ b/scripts/make-gpt.sh @@ -41,8 +41,25 @@ shift nl=$'\n' table="label: gpt" -# Keep 1MiB free at the start, and 1MiB free at the end. -gptBytes=$TWO_MiB +TEMP=`getopt -o g:: --long gptoffset:: -- "$@"` +eval set -- "$TEMP" + +while true ; do + case "$1" in + -g|--gptoffset) + gptBytes=$2 ; shift 2 ;; + --) shift ; break ;; + *) break ;; + esac +done + +if [ -z "$gptBytes" ] +then + gptBytes=${TWO_MiB} +fi + +FIRST_LBA="$(expr ${gptBytes} / 1024)" + for partition; do sizeMiB="$(sizeMiB "$(partitionPath "$partition")")" table="$table${nl}size=${sizeMiB}MiB,$(awk -f "$scriptsDir/sfdisk-field.awk" -v partition="$partition")" @@ -52,6 +69,7 @@ done rm -f "$out" truncate -s "$gptBytes" "$out" sfdisk "$out" <<EOF +first-lba: ${FIRST_LBA} $table EOF -- 2.25.1

2 1

[PATCH] EFI Loader: use correct arch suffix
by Ivan Nikolaenko 29 Sep '22

29 Sep '22

Previously there were hardcoded "x64" in EFI loaders' filenames. Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko(a)unikie.com> --- img/combined/default.nix | 5 +++-- img/live/Makefile | 2 +- img/live/default.nix | 5 +++-- nix/eval-config.nix | 11 ++++++++++- 4 files changed, 17 insertions(+), 6 deletions(-) diff --git a/img/combined/default.nix b/img/combined/default.nix index 3989d55..2086973 100644 --- a/img/combined/default.nix +++ b/img/combined/default.nix @@ -7,6 +7,7 @@ let inherit (builtins) storeDir; inherit (pkgs.lib) removePrefix; + inherit (config) archSuffix; eosimages = import ./eosimages.nix { inherit config; }; @@ -74,8 +75,8 @@ let done mcopy -i $out ${grub}/share/grub/unicode.pf2 ::/grub/fonts - grub-mkimage -o grubx64.efi -p "(hd0,gpt1)/grub" -O ${grub.grubTarget} part_gpt fat - mcopy -i $out grubx64.efi ::/EFI/BOOT/BOOTX64.EFI + grub-mkimage -o grub${archSuffix}.efi -p "(hd0,gpt1)/grub" -O ${grub.grubTarget} part_gpt fat + mcopy -i $out grub${archSuffix}.efi ::/EFI/BOOT/BOOT${lib.toUpper archSuffix}.EFI fsck.vfat -n $out ''; diff --git a/img/live/Makefile b/img/live/Makefile index 9815c88..e63c598 100644 --- a/img/live/Makefile +++ b/img/live/Makefile @@ -36,7 +36,7 @@ build/boot.fat: $(KERNEL) $(INITRAMFS) $(SYSTEMD_BOOT_EFI) build/spectrum.conf $(MCOPY) -i $@ build/spectrum.conf ::/loader/entries $(MCOPY) -i $@ $(KERNEL) ::/spectrum/linux $(MCOPY) -i $@ $(INITRAMFS) ::/spectrum/initrd - $(MCOPY) -i $@ $(SYSTEMD_BOOT_EFI) ::/EFI/BOOT/BOOTX64.EFI + $(MCOPY) -i $@ $(SYSTEMD_BOOT_EFI) ::/EFI/BOOT/$(EFINAME) # veritysetup format produces two files, but Make only (portably) # supports one output per rule, so we combine the two outputs then diff --git a/img/live/default.nix b/img/live/default.nix index 65ad058..7be55ac 100644 --- a/img/live/default.nix +++ b/img/live/default.nix @@ -4,7 +4,7 @@ { config ? import ../../nix/eval-config.nix {} }: let - inherit (config) pkgs; + inherit (config) pkgs archSuffix; inherit (pkgs.lib) cleanSource cleanSourceWith hasSuffix; extfs = pkgs.pkgsStatic.callPackage ../../host/initramfs/extfs.nix { @@ -33,7 +33,8 @@ stdenvNoCC.mkDerivation { INITRAMFS = initramfs; KERNEL = "${rootfs.kernel}/${stdenv.hostPlatform.linux-kernel.target}"; ROOT_FS = rootfs; - SYSTEMD_BOOT_EFI = "${systemd}/lib/systemd/boot/efi/systemd-bootx64.efi"; + SYSTEMD_BOOT_EFI = "${systemd}/lib/systemd/boot/efi/systemd-boot${archSuffix}.efi"; + EFINAME = "BOOT${lib.toUpper archSuffix}.EFI"; buildFlags = [ "build/live.img" ]; makeFlags = [ "SCRIPTS=${scripts}" ]; diff --git a/nix/eval-config.nix b/nix/eval-config.nix index 467f877..4234321 100644 --- a/nix/eval-config.nix +++ b/nix/eval-config.nix @@ -8,6 +8,15 @@ else {} }: -({ pkgs ? import <nixpkgs> {} }: { +({ pkgs ? import <nixpkgs> {} }: with pkgs; { inherit pkgs; + + archSuffix = + if pkgs.stdenv.isx86_64 then + "x64" + else if pkgs.stdenv.isAarch64 then + "aa64" + else + throw "Unsupported architecture"; + }) config -- 2.25.1

2 2

[PATCH] img/live: use callPackage function instead of "with pkgs;"
by Yuri Nesterov 27 Sep '22

27 Sep '22

When cross compiling Spectrum OS for aarch64 it tries to run aarch64 binaries on x64 host. To fix this issue it is possible to add pkgsBuildHost prefix to all native build inputs. However, a better option would probably be to use callPackage function. With that change it is able to automatically select correct packages. Signed-off-by: Yuri Nesterov <yuriy.nesterov(a)unikie.com> --- img/live/default.nix | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/img/live/default.nix b/img/live/default.nix index 5461384..1fa8da3 100644 --- a/img/live/default.nix +++ b/img/live/default.nix @@ -1,7 +1,11 @@ # SPDX-License-Identifier: MIT # SPDX-FileCopyrightText: 2021-2022 Alyssa Ross <hi(a)alyssa.is> +# SPDX-FileCopyrightText: 2022 Unikie -{ config ? import ../../nix/eval-config.nix {} }: +{ config ? import ../../nix/eval-config.nix {} }: config.pkgs.callPackage ( + +{ stdenvNoCC, cryptsetup, dosfstools, jq, mtools, util-linux, stdenv +, systemd }: let inherit (config) pkgs; @@ -15,8 +19,6 @@ let initramfs = import ../../host/initramfs { inherit config rootfs; }; in -with pkgs; - stdenvNoCC.mkDerivation { name = "spectrum-live.img"; @@ -48,3 +50,4 @@ stdenvNoCC.mkDerivation { passthru = { inherit rootfs; }; } +) {} -- 2.34.1

2 1