seccomp: add SYS_getcwd (79) to support proper Rust backtraces

When a proper Rust backtrace is printed, the Rust std wants to use the
SYS_getcwd(79) system call to prettify some paths while printing

seccomp: add SYS_getcwd (79) to support proper Rust backtraces

When a proper Rust backtrace is printed, the Rust std wants to use the
SYS_getcwd(79) system call to prettify some paths while printing. In
Cloud Hypervisor, this is at least relevant for printing panics or if
a `anyhow::Error` value is printed using `{e:?}` (but not `{e:#?}`).

The syscall cause can be found in `impl fmt::Display for Backtrace {}`
in `library/std/src/backtrace.rs`.

Without this addition, the seccomp violation of the SYS_getcwd (79)
hinders the proper error message including a full backtrace from showing
up. This annoying behaviour already delayed many debugging efforts. With
this fix, things just work. The new syscall itself should be pretty
harmless for normal operation.

```
thread 'vmm' panicked at virtio-devices/src/rng.rs:224:9:
Yikes, things went horribly wrong!

==== Possible seccomp violation ====
Try running with `strace -ff` to identify the cause and open an issue: https://github.com/cloud-hypervisor/cloud-hypervisor/issues/new
[1] 287683 invalid system call (core dumped) RUST_BACKTRACE=full cargo run --bin cloud-hypervisor -- --api-socket --kerne
```

```
thread 'vmm' panicked at virtio-devices/src/rng.rs:224:9:
Yikes, things went horribly wrong!
stack backtrace:
0: 0x557d91286b62 - std::backtrace_rs::backtrace::libunwind::trace::hc20b48b31ee52608
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library/std/src/../../backtrace/src/backtrace/libunwind.rs:117:9
1: 0x557d91286b62 - std::backtrace_rs::backtrace::trace_unsynchronized::h5d207cd20f193d88
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library/std/src/../../backtrace/src/backtrace/mod.rs:66:14

...

67: 0x0 - <unknown>
Error: Cloud Hypervisor exited with the following error:
Failed to join on VMM thread: Any { .. }

Debug Info: ThreadJoin(Any { .. })
```

- add any panic, for example into the create or drop function of a
device
- add --seccomp=true|log to analyze the situation

Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
On-behalf-of: SAP philipp.schuster@sap.com

show more ...

ci: Update reference kernel to 'v6.12.8-20250613'

This bump also includes another release 'ch-release-v6.12.8-20250422'
that changed the naming convention of the released kernel binaries
[1]. As a r

ci: Update reference kernel to 'v6.12.8-20250613'

This bump also includes another release 'ch-release-v6.12.8-20250422'
that changed the naming convention of the released kernel binaries
[1]. As a result, few changes are made to our integration tests and test
scripts.

[1] https://github.com/cloud-hypervisor/linux/releases/tag/ch-release-v6.12.8-20250422

Signed-off-by: Bo Chen <bchen@crusoe.ai>

show more ...

ci: improve gitlint (max line length in body with exceptions)

Follow-up of 5aa1540c5dc33d61020a08dd2818c0f5fd08575f but way more
mature. We now use custom gitlint rules written in Python to better
h

ci: improve gitlint (max line length in body with exceptions)

Follow-up of 5aa1540c5dc33d61020a08dd2818c0f5fd08575f but way more
mature. We now use custom gitlint rules written in Python to better
handle the max line length, with respect to a few valid exceptions.
Recognizing code blocks or compiler output, as discussed, is not
trivial and hard to get right for all corner-cases. Therefore, this
commit is a pragmatic way forward. The CI job should be kept optional.

Allowed exceptions for the 72 line length limit are now:

1. links in the following three common patterns:
https://example.com/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links
[0] https://example.com/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links
[0]: https://example.com/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links

2. code blocks (anything between the three backticks)

```
let x = "very_long_very_long_very_long_very_long_very_long_very_long_very_long_very_long_very_long_very_long_"
```

Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
On-behalf-of: SAP philipp.schuster@sap.com

show more ...

build: Bump MSRV to 1.83.0

The dependency `bitfield-struct` 0.10.x of `igvm` 0.3.5 requires MSRV
1.83.0, bump to catch up.

Update image to 20250412-0 because MSRV in Dockerfile is updated.

Signed-

build: Bump MSRV to 1.83.0

The dependency `bitfield-struct` 0.10.x of `igvm` 0.3.5 requires MSRV
1.83.0, bump to catch up.

Update image to 20250412-0 because MSRV in Dockerfile is updated.

Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>

show more ...

build: Bump MSRV to 1.82.0

We are having complains from Rust 1.86.0-beta.1 (f0cb41030 2025-02-17)'
clippy, which suggests us to replace `repeat().take()` with
`repeat_n()`. While `repeat_n()` is sta

build: Bump MSRV to 1.82.0

We are having complains from Rust 1.86.0-beta.1 (f0cb41030 2025-02-17)'
clippy, which suggests us to replace `repeat().take()` with
`repeat_n()`. While `repeat_n()` is stablized in Rust 1.82.0.

Update image to 20250307-2 because MSRV in Dockerfile is updated.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>

show more ...

build: Fix spdk in linux/arm64 image

The reason `test_vfio_user` fails is as @likebreath pointed: our ARM
host does not support SVE, while the nvme_tgt binary built from the
container image requires

build: Fix spdk in linux/arm64 image

The reason `test_vfio_user` fails is as @likebreath pointed: our ARM
host does not support SVE, while the nvme_tgt binary built from the
container image requires it. As a result, we encountered a SIGILL when
running the nvme_tgt binary. This also explains why this is not
happening when the container is built on the same host itself.

And quote from @rbradford:

When a job is run on one of the workers it looks to see if there is a
container locally matching the name as specified in the dev_cli.sh
script - if there is then it uses it. Otherwise it will try and download
it from the container registry - if that fails then it will built
locally. For the x86-64 workers started dynamically it will never have a
local version as they are a fresh VM. But on the ARM64 builder is a
local container image cache.

This can lead to an issue where if the image is build with one version
(a handcrafted datestamp) and then the Dockerfile is changed without
changing the timestamp then an old version may be fetched from the cache
or server. It is there for essential to always bump the datestamp (there
is a number after the - that can be used for this.)

However there is also the added complexity that image that is build and
uploaded to the container registry is not the same as the built locally
and thus used for the initial testing of the Dockerfile change. This
leads to the issue we have seen where different CPU compiler flags (from
-march=native) from the QEMU cross build in the hosted GHA action and
the local ARM64 build. Resulting in a binary in the remotely built
container not working locally.

We end up specifying TARGET_ARCHITECTURE="armv8.2-a" for building spdk,
and put built `python/spdk/` folder into `/usr/local/bin/spdk-nvme`.

Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>

show more ...

scripts: Remove SPDK build in aarch64 test script

We already build `SPDK` for `linux/arm64` in our `Dockerfile`, no need
to build it here anymore.

Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>

build: Upgrade to 24.04 in Dockerfile

`arm64` build in ubuntu:22.04 errors out with `error processing package
libc-bin`. This issue is a known issue between the binfmt (running
different architectur

build: Upgrade to 24.04 in Dockerfile

`arm64` build in ubuntu:22.04 errors out with `error processing package
libc-bin`. This issue is a known issue between the binfmt (running
different architectures via QEMU) and the libc ldconfig binary running
in container. We're "suddenly" having issues as ubuntu-latest (which is
the OS version we run the GH action container with) was recently changed
from 22.04 to 24.04 and hence why upgrading the container userspace from
22.04 to 24.04 solves the problem.

Removed deprecated package `python3-distutils`.

Update image name from `20250111-0` to `20250222-0`.

Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>

show more ...

docs: Update documentation for new kernel configuration

Replace the use of a reference kernel configuration file from this
repository with the use of a defconfig from the linux fork.

Signed-off-by:

docs: Update documentation for new kernel configuration

Replace the use of a reference kernel configuration file from this
repository with the use of a defconfig from the linux fork.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

show more ...

build: Switch to named released kernel binary

For more control over updating the guest kernel use a fixed tag name
rather than fetching the latest.

Signed-off-by: Rob Bradford <rbradford@rivosinc.c

build: Switch to named released kernel binary

For more control over updating the guest kernel use a fixed tag name
rather than fetching the latest.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

show more ...

tests: Bump OVMF version

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

scripts: Temporarily build kernel as part of CI

Updating the kernel to v6.12 has shown up a flaw in the workflow for our
binary kernel releases. The CI job that builds the binary kernel in the
cloud

scripts: Temporarily build kernel as part of CI

Updating the kernel to v6.12 has shown up a flaw in the workflow for our
binary kernel releases. The CI job that builds the binary kernel in the
cloud-hypervisor/linux repository fetches the config from the main
branch of the cloud-hypervisor/cloud-hypervisor repository. However the
CI job to update the kernel version to use is in the cloud-hypervisor
repository.

As a workaround - update the kernel config and version in the
cloud-hypervisor repository to point to v6.12 and use the ability to
build the kernel during the CI run. Once merged to main a new release
can be made in the linux respository which will build a binary asset
using the new config. After that release the CI jobs on the
cloud-hypervisor repository can changed back to using the binary kernel
assets.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

show more ...

build: Update kernel to v6.12

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

build: Bump version number of Docker image

No change to the Dockerfile but I observed that the 20251022-0 image was
not available in the repository.

Signed-off-by: Rob Bradford <rbradford@rivosinc.

build: Bump version number of Docker image

No change to the Dockerfile but I observed that the 20251022-0 image was
not available in the repository.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

show more ...

scripts: Reduce number of parallel jobs on ARM64 CI

This system is erroring out on jobs due to insufficient memory - reduce
parallelism to allow CI jobs to complete.

Signed-off-by: Rob Bradford <rb

scripts: Reduce number of parallel jobs on ARM64 CI

This system is erroring out on jobs due to insufficient memory - reduce
parallelism to allow CI jobs to complete.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

show more ...

ci: Constrain FW_URL to x86_64 one

With 0.5.0 release of `rust-hypervisor-firmware`, `aarch64` binary were
added to assets, which causes the `FW_URL` to have multiple download url
separated by a whi

ci: Constrain FW_URL to x86_64 one

With 0.5.0 release of `rust-hypervisor-firmware`, `aarch64` binary were
added to assets, which causes the `FW_URL` to have multiple download url
separated by a white space, thus our integration tests would fail.

Constrain `FW_URL` to `hypervisor-fw` to resolve this.

Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>

show more ...

scripts: Replace download_linux with prepare_linux

`prepare_linux` is capable of determining whether we need to invoke
`build_custom_linux` for building linux from source or `download_linux`
for dow

scripts: Replace download_linux with prepare_linux

`prepare_linux` is capable of determining whether we need to invoke
`build_custom_linux` for building linux from source or `download_linux`
for downloading pre-built.

Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>

show more ...

scripts: Add prepare_linux function

`prepare_linux` checks if a `--build-guest-kernel` option is present,
and build kernel from `cloud-hypervisor/linux.git`. Otherwise, it will
invoke `download_linu

scripts: Add prepare_linux function

`prepare_linux` checks if a `--build-guest-kernel` option is present,
and build kernel from `cloud-hypervisor/linux.git`. Otherwise, it will
invoke `download_linux` to use pre-built kernel.

Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>

show more ...

scripts: Add consistency check script

Add `package-consistency-check.py` script to prevent #6809 and #6815
from happening. This script takes a string present in the repository
field of packages to i

scripts: Add consistency check script

Add `package-consistency-check.py` script to prevent #6809 and #6815
from happening. This script takes a string present in the repository
field of packages to identify pacakges from a specific source.

Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>

show more ...

scripts: fix code coverage script args parsing

Signed-off-by: Songqian Li <sionli@tencent.com>

build: Bump dev container version

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

tests: Limit number of test thread on aarch64

This system has a lot of cores (80) resulting in all the tests being
spawned simultaneously and leading to exhaustion of the available
memory. Instead l

tests: Limit number of test thread on aarch64

This system has a lot of cores (80) resulting in all the tests being
spawned simultaneously and leading to exhaustion of the available
memory. Instead limit the number of threads.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

show more ...

tests: Update version of Jammy image in use

This version is generated with the new script and adds kexec-tools.

Fixes: #6726

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

scripts: Add a script to automate the custom image construction

Only for x86-64 right now but does include support for custom VFIO
image.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

scripts: Only download kernel binaries if changed

Only download the kernel binaries from the github release if the remote
file is newer (avoids multiple copies accumulating in the download
directory

scripts: Only download kernel binaries if changed

Only download the kernel binaries from the github release if the remote
file is newer (avoids multiple copies accumulating in the download
directory.)

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

show more ...