Skip to content

Bump patchset: v51 -> v52#158

Closed
phip1611 wants to merge 178 commits into
cyberus-technology:gardenlinux-next-v52-basefrom
phip1611:gardenlinux-next-v52
Closed

Bump patchset: v51 -> v52#158
phip1611 wants to merge 178 commits into
cyberus-technology:gardenlinux-next-v52-basefrom
phip1611:gardenlinux-next-v52

Conversation

@phip1611
Copy link
Copy Markdown
Member

@phip1611 phip1611 commented May 20, 2026

This series bumps the gardenlinux Cloud Hypervisor patchset onto the recently released v52.

You can find an overview of the difficulties during the rebase in this outline document (trivial patches, hard to rebase patches, patches that are now upstream...).

From ~250 commits we have in the current gardenlinux branch, we are now down to ~170.

Changes & Hints for Reviewers

  • libvirt pipeline run: https://gitlab.cyberus-technology.de/cyberus/cloud/libvirt/-/merge_requests/194/pipelines
  • The original commits that are still there, exist with the same name in the old gardenlinux branch (minor exceptions might be possible)
    • with a few minor exceptions to streamline commits that belong to a series
  • I reordered the patchset quite significantly: small standalone commits are mostly moved to the beginning where it makes sense, followed by larger series
    • Only exception is TLS, as I expected TLS to be merged before the v52 release
  • All commits of series where consolidated, moved together, and sometimes even squashed (init A -> ... -> fix A commits where squashed)
    • This especially applies to the CpuProfile-related commits
  • For example, the whole CPU Profiles effort is now a single commit series at the end of our patchset
  • This was by far the toughest patchset rebase we had so far
  • Beware: I am unfortunately pretty sure that I've missed minor changes of our gardenlinux branch in that rebase process. For example, some error message improvement or so, but nothing major. This comes from the nature of this complex operation I had to do here.
  • Changes I had to do against upstream to work with our stack:
    • rename pci_device_id from upstream back to bdf_device to be compatible with us
    • remove mutual TLS (mTLS) (use normal TLS)
    • Command::CompletePaused from upstream (NEW) clashes with Command::KeepAlive` (our fork)
  • I updated the flake inputs (nixpkgs, rust tooling) and merged it with the flake: init commit
  • Included backports (from upstream after v52)

The result is a shorter and more reviewable branch than
cyberus-github/gardenlinux while preserving the relevant Gardenlinux behavior
on top of the current Cloud Hypervisor base.

Ticket: https://github.com/cobaltcore-dev/cobaltcore/issues/503#issuecomment-4311454443

rbradford and others added 30 commits May 19, 2026 12:40
@rbradford @phip1611
vmm: Revert "vmm: create memfd for private mappings"
5cc8d31 
This reverts commit ced3762.

This change lead to a serious memory regression when not using hugepages
or shared=on.

`MAP_PRIVATE` creates an anonymous memory allocation for every page
written when the backing store is a file. This CoW behaviour is useful
but leads to double allocations when the backing store is an empty file
created by `memfd_create()`. When the page is written to, the CoW
semantics require a real page to be created in the memory for the memfd
(previously before the page was touched they would all point to the zero
page). This real page is filled with zeroes because in theory this page
would be accessible via read/write syscalls on the FD even though in our
implementation it is only ever `mmap()`ed.

The intention of the commit was to enable `fallocate()` to be used to
punch holes but that would only affect the inaccessible backing page and
the page in the CoW anonymous memory would be unaffected. Leading it
likely not to have the desired effect.

Fixes: cloud-hypervisor#8211

Signed-off-by: Rob Bradford <rbradford@meta.com>
@phip1611
vm-migration: be explicit about commands
1336d26 
Reordering commands or adding commands in-between is breaking the
migration protocol. By using explicit numbers, we can increase the
attention required when touching this code.

On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
@phip1611
vmm: migration: better observe and log invalid states
b925a00 
This increases debugability.

On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
@rbradford @phip1611
vmm: Don't store the snapshot on the DeviceManager
0de3ba7 
Storing the snapshot causes issues when needing to do a subsequent
hotplug instead just pass it through on all the methods that need it
making the lifecycle cleaner.

Assisted-by: Claude:Opus-4.6
Signed-off-by: Rob Bradford <rbradford@meta.com>
@amphi @phip1611
vmm: remove redundant SocketStream overrides
6effdc2 
ReadVolatile already provides a default read_volatile_exact()
implementation, and WriteVolatile a default write_volatile_exact()
implementation. Overriding these functions adds no behavioral value, but
duplicates logic and needs to be updated whenever SocketStream gains or
changes a variant.

On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
@amphi @phip1611
vmm: remove AsRawFd trait for SocketStream
aacc763 
The trait is not used and thus can be removed.

On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
@amphi @phip1611
vm-migration: client-side of a TLS connection
e20f19f 
TLS connections have a TLS server (listens for incoming connections) and
a TLS client (initiates the connection). This commit adds the code for
the client side, which is the sender of a migration

On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
@amphi @phip1611
vm-migration: server-side of a TLS connection
b8cc358 
Code for the TLS server, i.e. the receiver of a live migration.

On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
@amphi @phip1611
vmm: add TLS streams to migration transport
a8e538e 
Teach the migration transport to handle TLS-backed streams alongside
plain TCP and UNIX sockets.

Introduce a Tls variant in SocketStream and implement the necessary
traits.

Also updates the local-migration error path to reject any non-UNIX
transport, which now includes TLS-wrapped TCP connections.

On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
@amphi @phip1611
vmm: accept migration connections over TLS
99bfc0b 
Extend ReceiveListener with a TLS-backed listener variant for migration
receivers.

Store the TCP listener together with the server TLS configuration, wrap
accepted sockets in TlsStream::new_server(), and preserver the existing
listener cloning and fd polling behavior so receive-side migration code
can treat TLS listeners like the existing TCP and UNIX cases.

On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
@amphi @phip1611
vmm: tighten migration URL validation
93f4029 
For TLS we have to parse the hostname from the given migration URL. For
that we have to make a few assumptions about the URL (e.g. it always has
a port). To catch problems early, we tighten the URL validation.

On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
@amphi @phip1611
vmm: add TLS API option to send migration call
96abfb4 
To enable TLS, the caller has to provide a path to a directory that
contains the necessary files.

On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
@amphi @phip1611
vmm: add TLS API option to receive migration call
0111b16 
As we now have more than one parameter for the receive migration call,
this commit also adds parsing and validation for those parameters. We
maintain backwards compatibility by also correctly parsing the case
where the caller only provides a URL.

On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
@amphi @phip1611
vmm: encrypt migration data with TLS if configured
9c064fd 
Wire in the code paths that activate the TLS encrypting if the necessary
API arguments are provided.

On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
@amphi @phip1611
docs: document live migration TLS encryption
b7cd61e 
On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
@phip1611
docs: update README for gardenlinux Cloud Hypervisor
1a14b83 
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
On-behalf-of: SAP philipp.schuster@sap.com
@phip1611
misc: adjust AGENTS.md for our fork
696ef51 
On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
@phip1611
ci: enforce SAP commit style
e765e69 
To check gitlint locally, one can run:

gitlint --commits "HEAD~2..HEAD"

which for example checks the last two commits.

Although this is just our kinda private (but public) fork, people might
cherry-pick commits from us for whatever reason. So we should have
proper commit style.

On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
@phip1611
ci: remove irrelevant CI for this fork
e84b16d 
Remove irrelevant/annoying CI here to accelerate development. Further,
we don't have the runners to run the integration tests, but at least
we want to run the unit tests, clippy, etc.

Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
On-behalf-of: SAP philipp.schuster@sap.com
@phip1611
build: flake: init
6440bd9 
Adds a flake configuration that enables building Cloud Hypervisor
directly from this repository using Nix.

This makes it possible to deploy and test Cloud Hypervisor on NixOS
systems in real environments.

On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
@arctic-alpaca @phip1611
build: nix: add commit to version info
14803af 
Sets the `CH_EXTRA_VERSION` env var during compilation to add the git
revision to the version output.

On-behalf-of: SAP julian.schindel@sap.com
Signed-off-by: Julian Schindel <julian.schindel@cyberus-technology.de>
@phip1611
build: ci/nix: build cloud-hypervisor
7e43a27 
On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
@phip1611
build: cargo: add optimized-dev profile
164f96f 
TL;DR: Fix for long rebuilds locally when testing things.

The release profile is optimized for maximum performance,
sacrificing build speed. As local development and testing requires
frequent rebuilds, but the dev profile is way too slow for
"real testing", this profile is a sweet spot and helps to
investigate things.

Instead of `cargo run --release`, one can now run
`cargo run --profile optimized-dev`.

# Measurements

Measurements were done using
`$ [cargo clean;] time cargo build --profile release|optimized-dev` and
rustc 1.89. I've used the `time`-builtin from zsh.

Note that user time is much higher as we have more threads
(codegen units) now. The total time is much shorter, tho.

## Clean Build

Speedup of 56%.

- `$ time cargo clean --release`:
  `109,67s user 13,64s system 211% cpu 58,343 total`
- `$ time cargo clean --profile optimized-dev`:
  `185,41s user 14,92s system 528% cpu 37,876 total`

## Incremental Build

Speedup of 153%.

- `$ time cargo clean --release`:
  `37,58s user 1,53s system 117% cpu 33,356 total`
- `$ time cargo clean --profile optimized-dev`:
  `47,62s user 1,71s system 373% cpu 13,220 total`

Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
On-behalf-of: SAP philipp.schuster@sap.com
@phip1611
build: cargo: don't strip binary
c62a95b 
With debug symbols, we will get better backtraces and can
improve our experience debugging. The only downside is larger
binary size which is negligible in our case. There are no
implications for the performance.

Stripped:   3.9M
Unstripped: 4.7M

Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
On-behalf-of: SAP philipp.schuster@sap.com
@phip1611
main: print build version and date on startup
ca62d52 
This improves the quality of the logs when debugging issues. I've used
the `jiff` time library as it is well-known time library of the
ecosystem.

Now, the first logging message (level info!) looks somewhat like this:

```text
Cloud Hypervisor starting: build version: v51.1-203-g7f0f1f5cb-dirty, date: 2026-03-30T14:42:30.00730185+02:00
```

On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
@phip1611
vmm: cpu: improve timeout handling in wait_until_signal_acknowledged()
6d3ca5d 
We've seen big VMs under massive load that regularly fired their
`"vCPU thread did not respond in {count}ms to signal - retrying` warning
message. So far, all such situations recovered themselves after ~600ms.
To be more fail-safe for the production environment under load, we
increase this timeout to 10s.

On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
@phip1611
vmm: increase logging level of precopy from debug -> info
bdc95e3 
This is very helpful information in the field where libvirt just
sets the info level. This retains the behavior that we already have at
our customer. Further, our tests rely on that line to check the
migration progresses.

On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
@phip1611
vmm: pci: rename pci_device_id -> device_id
669ef2a 
This is a temporary measurement as upstream decided for a different name
than we in our fork.

On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
@phip1611
main: restore absolute timestamp behavior in logger
1ebc727 
This includes the timezone again.

On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
@phip1611
misc: live-migration with virtio-net devices with network fds
0741bb9 
This allows to attach FDs provided by the management layer to virtio-net
devices on the live-migration receiver side.

Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
On-behalf-of: SAP philipp.schuster@sap.com
@olivereanderson @phip1611
arch: Add a list of all Intel architectural MSRS
3494df1 
This list will be used to help us detect unknown MSRs when generating
CPU profiles. It serves no other purpose beyond that.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Address architectural msrs review
3cb07a7 
TODO: Squash into previous commit if this all works as expected

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Include a list of non-architectural MSRs
0355bed 
We include a list of non-architectural MSRS. This list will only be
used to help the CPU profile generation tool rule out MSRs that it
does not know how to handle.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Add lists of KVM MSRS
8203200 
We include a list of MSRS defined by KVM that may be approved by
CPU profiles and another list of those that may not be approved by
CPU profiles. These lists will later be used by the CPU profile
generation tool.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Add a list of HyperV MSRs
9b0f3a5 
The list of HyperV MSRs introduced here will be utilized during CPU
profile generation and also at runtime to filter them out whenever
`kvm_hyperv` is set to `false`.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Add required MSR update functionality
1611c7b 
We introduce functionality related to computing necessary MSR updates
in accordance with the given CPU profile.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Deny MSR functionality
08b416b 
We introduce functionality to filter out MSRs which we want to deny
guests from using.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
vmm: Apply MSR adjustments according to CPU profile (if any)
9589416 
We record the necessary MSR-based feature modifications that need to be
set in the `CpuManager` and make sure to set these MSR values upon
vCPU configuration. We also use the Vm to filter access to MSRs that
are incompatible with the chosen CPU profile.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Make the CPU profile generation tool MSR aware
43cf47d 
We adapt the CPU profile generation tool to also take the MSR-based
features into account.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Use MSR aware profiles
4ecf665 
We regenerate the CPU profiles and include the MSR-related data.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Inherit policy for MCA
e58b065 
Windows server needs the machine check architecture (MCA) CPUID bit to
be set in order to boot.

Since Windows server is a use-case we want to support we need to revert
our previous decision to disable MCA for non-host CPU profiles.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Permit IA32_MCG_CAP and IA32_MCG_STATUS
3fef033 
We permit these MSRs because they are expected to be available when
the CPUID 0x1.EDX[14](MCA) feature bit is set. Recall that MCA is
necessary in order to boot Windows Server which we want to support.

We also do not list the error reporting banks as forbidden any longer.
Aside: The previous implementation did not end up denying those MSRs
anyway, because KVM does not report them via KVM_GET_MSR_INDEX_LIST.
Now with MCA explicitly set, the guest will certainly expect the
presence of error reporting banks, so we make sure not to indicate
otherwise.

Recall that by default KVM reports all (32) error banks as available
and leaves all feature bits of IA32_MCG_CAP unset, hence the
information displayed to the guest in these MSRs will remain consistent
before and after a live migration in the absence of machine check
errors.

Note that as of today Cloud hypervisor does not transfer the error
reporting banks to the destination of a live migration which can indeed
lead to surprises, but on the other hand the information is likely to
be inaccurate at the point of resume anyway.

As a follow up we could try to mitigate the aforementioned problem
by checking for MCEs during live migration and marking the migration
as failed if any MCE occurred before or during the live migration.
That should however be addressed in a separate PR.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Regenerate CPU profiles
1637bad 
Regenerate CPU profiles in order to enable machine check architecture
(MCA) for non-host CPU profiles which is required to boot Windows
server.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: FORDIB IA32_U_CET and IA32_S_CET in CPU Profiles
e260fdd 
These are already displayed as not available to guests via CPUID for
non-host CPU profiles, but we forgot to forbid the corresponding MSRs.

The profiles we have generated are OK with respect to this oversight
because KVM_GET_MSR_INDEX_LIST did not report those MSRs at the time
they were generated, but it does now.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Disable HDC state components for CPU profiles
ae259e7 
Hardware duty cycling (HDC) does not make sense in the virtualization
setting and should thus not be displayed as available to guests.

We have already disabled certain HDC aspects via CPUID 0x6 ECX[13],
but we forgot to disable the state components which is what we do
in this commit.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Disable LBR state components
0cd09a8 
We have already disabled architectural LBR (last branch record) for CPU
profiles, but we forgot to disable the corresponding state components.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Disable HWP state components
0268e18 
Hardware P-states (HWP) is already disabled for non-host CPU profiles,
but we forgot to also disable the associated state components.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Disable PT state components
1bb570e 
We already disabled Processor Trace (PT) for CPU profiles, but forgot
to disable the associated state components.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Disable PASID state components
e986596 
We have already forbidden IA32_PASID, an MSR related to process
address space identifiers (PASID), but we forgot to disable the
associated state components.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Disable VM_ENTRY_HARDWARE_EXCEPTIONS for CPU profiles
e7cb160 
Bit 56 of VM_ENTRY_HARDWARE_EXCEPTIONS in IA32_VMX_BASIC is only
set on rather recent KVM versions.

Thus whenever a CPU profile is generated on a machine with a recent
Linux kernel, the current inherit policy will lead to the CPU profile
being incompatible on deplyoments with older Linux kernels. This may
not be the intention of the person generating the CPU profile, thus
we change the policy to `Static(0)` for the time being.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Forbid IA32_XSS for non-host CPU profiles
b87cc40 
IA32_XSS (Extended Supervisor State Mask) is only reported via
KVM_GET_MSR_INDEX_LIST on rather recent kernels. This can lead to CPU
profiles that are generated on a machine with the latest Linux kernel,
not work with deployments where the hosts use a bit older kernels which
may be unintentional.

We thus decide to forbid this MSR for now, even though
CPUID 0xd.0x1.EAX[3] can inform the guest that the MSR is available.
We do not want to force the aforementioned feature bit to 0 because
it is also used to report support for XSAVES/XRSTORS.

Although not ideal, we consider denying access to IA32_XSS to be
acceptable because the 0xd CPUID leaves report all IA32_XSS related
state components to be unsupported. There is thus no reason for the
guest to be interested in using this MSR.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Clear LBR related bits in the VM-Exit and VM-Entry CTL MSRs
66d3038 
We have disabled LBR for non-host CPU profiles, but forgot to also do
so in the VM-Exit and VM-Entry control MSRs.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
docs: CPU Profile generation
9367e67 
We add developer documentation on how to use the CPU profile generation
tool.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
build: flate2 Workspace dependency
2e0a642 
We will later use flate2 in arch/build.rs to compress CPU profile
JSON files at compile time and also later to decompress them at
runtime.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Code generation for CPU profiles
b4293d6 
We introduce a build.rs build script in the arch crate which
automatically constructs the x86_64 CpuProfile enum with one variant
per pre-generated CPU profile.

In order to keep the binary size in check we also take the opportunity
to compress the CPU profile JSON files into the binary which then get
decompressed at runtime.

We will adapt cpu_profile.rs in the next commit to use the output
of build.rs

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Update cpu_profile.rs to include code generation from build.rs
e566ed3 
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
docs: Update CPU profile generation developer documentation
fc6e510 
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@olivereanderson @phip1611
arch: Deserialize CPU profiles in kebab-case
e161b7f 
When we introduced our build script we forgot to tell `serde` to
(de-) serialize the `CpuProfile` enum in kebab-case which is a breaking
change.

Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
@phip1611 phip1611 self-assigned this May 20, 2026
@phip1611 phip1611 closed this May 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@phip1611 phip1611

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

8 participants

@phip1611 @rbradford @amphi @arctic-alpaca @hertrste @Coffeeri @scholzp @olivereanderson