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>
`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>
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>
The ability to control the rustc flags (required for adding new
attributes to the allowed list of #[cfg(..)]) requires bumping the MSRV
to 1.77.0
Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
This removes the requirement to ensure that we land PRs that update the
Dockerfile (and the appropraite dev_cli.sh change) in a specific time
frame.
Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
Because of double quotes the current value is passed
as a single argument with a space in it to cargo.
This commit changes it to an array so each element
is passed as a different arguments.
Signed-off-by: Alexandru Matei <alexandru.matei@uipath.com>
The following tests have been temporarily disabled:
1. Live upgrade/migration test with ovs-dpdk (#5532);
2. Disk hotplug tests on windows guests (#6037);
This patch has been tested with PR #6048.
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@intel.com>
Signed-off-by: Michael Zhao <michael.zhao@arm.com>
Tested-by: Bo Chen <chen.bo@intel.com>
There is no need to set them in the test scripts while the main script
already has them.
The consolidates how things are done.
Signed-off-by: Wei Liu <liuwe@microsoft.com>
There is no need to reconstruct it from within the scripts since the
main script already constructed it once.
Drop the previously useless setting of BUILD_TARGET from various
scripts. The value was always overwritten at a later point.
No functional change intended.
Signed-off-by: Wei Liu <liuwe@microsoft.com>
When performing integration testing on the Ampere One server, an error occurred when compiling spdk and not recognizing the CPU ID.
The latest spdk already contains fixes.
Signed-off-by: dom.song <dom.song@amperecomputing.com>
As the container image can be used on both Intel and AMD,
ensure the SPDK binaries are compatible. This implies -march=skylake
passed to the underlaying toolchain.
Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
Currently if container registry is inaccessible the image will be built
locally and that takes time. This patch adds support to use mirror
registry. To use a different registry CTR_IMAGE environment variable
must be set. For example:
CTR_IMAGE="registry/cloud-hypervisor" scripts/dev_cli.sh
or
export CTR_IMAGE="registry/cloud-hypervisor"
scripts/dev_cli.sh
Signed-off-by: Ruslan Mstoi <ruslan.mstoi@intel.com>
Implemented a `TargetApi` enum to make the process of implementing
tests for the D-Bus and HTTP API more convenient.
Refactored `test_api_{create_boot, shutdown, pause_resume, delete}` tests
with the `TargetApi` enum to also implement tests for the D-Bus API.
Added a new test named `test_api_dbus_and_http_interleaved` that uses
both the HTTP and D-Bus API at the same time.
Modified integration test scripts to enable the `dbus_api` feature when
compiling and start a dbus-session when integration tests are run.
Signed-off-by: Omer Faruk Bayram <omer.faruk@sartura.hr>
Currently we are overwriting the RUST_BACKTRACE if set
explicitly by user while running performance metrics tests
using dev_cli.sh
This change will allow user to set the RUST_BACKTRACE
while running performance metrics tests with dev_cli.sh
which invokes run_metrics.sh to run the performance binary.
We will set RUST_BACKTRACE to 1 if not set explicitly.
Signed-off-by: smit-gardhariya <gardhariya.smit@gmail.com>
Unfortunately the build had a transient error and so needed to be
restarted which generated a build with a different date tag.
Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
This latest stable Rust toolchain can help reduce the final binary size
around ~300k when comparing with building with Rust 1.62. Specifically,
the binary size now is 3.3M (previously 3.6M) with default feature, and
4.0M (previously 4.2M) with "kvm+mshv" feature (e.g. our release action
build) .
Signed-off-by: Bo Chen <chen.bo@intel.com>
Right now integration test fails during the test run if
/dev/mshv or /dev/kvm does not exist. We should not
progress and exit early if not present.
Signed-off-by: Muminul Islam <muislam@microsoft.com>
This enables the Windows test module. One basic test is enabled,
while all others are disabled yet for aarch64. Jenkins file is
extended with the corresponding step for aarch64.
installAzureCli() is parametrized.
It seems that transferring a 30GB image would take >= 15 minutes. An
optimization here is having a gzip'ed image to 10GB which would unpack
in 3 minutes. Expect to be quicker than transferring an uncompressed
image while on another network.
Signed-off-by: Anatol Belski <ab@php.net>
These were erroneously skipping features for the unit tests and the
"build" target for dev_cli.sh
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
These are never run by the CI and is inconsistent with the way we build
test which is specified inside the .github workflows.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Adding the missing TARGET_CC environment variable to get the build to
complete correctly.
Fixes#3776
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Let's officially have a way to pass the features used to build
cloud-hypervisor to the dev_cli.sh script.
This doesn't invalidate the previous commit, as we still don't what the
features_build variable to be quoted, otherwise we face the following
issue:
```
error: Found argument '--features tdx' which wasn't expected, or isn't valid in this context
Did you mean --features?
USAGE:
cargo build --all --features <FEATURES>...
```
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
2805e7b1dc quoted enclose variables to
prevent globbing or incorrect splitting. However, by doing with with
$features_build it broke the capability to call the script as:
```
$ ./scripts/dev_cli.sh build --release --libc musl -- --features tdx
```
Before 2805e7b1dc it simply worked, after,
the result is:
```
docker run --user 1000:1000 --workdir /cloud-hypervisor --rm --volume /dev/kvm --volume /home/ffidenci/go/src/github.com/cloud-hypervisor/cloud-hypervisor:/cloud-hypervisor --env RUSTFLAGS= cloudhypervisor/dev:20220223-0 cargo build --all '' --target-dir /cloud-hypervisor/build/cargo_target --features tdx --release --target x86_64-unknown-linux-musl
error: Found argument '' which wasn't expected, or isn't valid in this context
USAGE:
cargo build --all
For more information try --help
```
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The dev container interface script (e.g. 'dev_cli.sh') now supports the
following arguments syntax for running tests:
`tests [--unit|--cargo|--all] [--libc musl|gnu] [-- [<test scripts args>] [-- [<test binary args>]]] `
In this way, we can pass custom arguments to the test binary (either
"cargo test" or "performance-metrics") with our dev container script.
For example:
`$ ./dev_cli.sh tests --metrics -- -- --report-file /tmp/metrics.json --test-filter latency`
`$ ./dev_cli.sh tests --integration -- --test-filter "test_serial" -- --nocapture --test-threads=1`
Fixes: #3739
Signed-off-by: Bo Chen <chen.bo@intel.com>
