As common isn't built for RISC-V architecture now, accordingly,
common/coverage (where __gconv_* function are defined) isn't built either
but randconfig may decide to enable CONFIG_COVERAGE which will lead to
the following compilation error:
riscv64-linux-gnu-ld: prelink.o: in function `.L0 ':
arch/riscv/early_printk.c:(.text+0x18):
undefined reference to `__gcov_init'
riscv64-linux-gnu-ld: arch/riscv/early_printk.c:(.text+0x40):
undefined reference to `__gcov_exit'
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
There's no need to do ad-hoc string parsing. Use grep -q instead.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Some testcases use a cross compiler. Presently it's only arm32 and due to
previous cleanup the only thing which is now wrong is printing the compiler
version at the start of day.
Construct $cc to match what `make` will eventually choose given CROSS_COMPILE,
taking care not to modify $CC. Use $cc throughout the rest of the script.
Also correct the compiler detection logic. Plain "gcc" was wrong, and
"clang"* was a bodge highlighting the issue, but neither survive the
CROSS_COMPILE correction. Instead, construct cc_is_{gcc,clang} booleans like
we do elsewhere in the build system, by querying the --version text for gcc or
clang.
While making this change, adjust cc_ver to be calculated once at the same time
as cc_is_* are calculated.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Whether to build only Xen, or everything, is a property of container,
toolchain and/or testcase. It is not a property of XEN_TARGET_ARCH.
Capitalise HYPERVISOR_ONLY and have it set by all the
debian-unstable-gcc-arm32-* testcases at the point that arm32 get matched with
a container that can only build Xen.
To reduce the churn elsewhere, retain the RANDCONFIG implies HYPERVISOR_ONLY
property.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This is purely code motion of the cfgargs construction, into the case where it
is used.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Preserve the artefacts based on the `make` rune we actually ran, rather than
guesswork about which rune we would have run based on other settings.
Note that the ARM qemu smoke tests depend on finding binaries/xen even from
full builds. Also the Jessie-32 containers build tools but not Xen.
This means the x86_32 builds now store relevant artefacts. No change in other
configurations.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Having 3 extra hypervisor builds on the end of a full build is deeply
confusing to debug if one of them fails, because the .config file presented in
the artefacts is not the one which caused a build failure. Also, the log
tends to be truncated in the UI.
PV-only is tested as part of PV-Shim in a full build anyway, so doesn't need
repeating. HVM-only and neither appear frequently in randconfig, so drop all
the logic here to simplify things.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add test jobs in both debug and non-debug versions to run hyp-xen-version
XTF test as a dom0less domU on arm64. The purpose of this test is to
validate the functional behavior of xen_version hypercall.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Introduce support for using XTF on Arm to perform low-level testing.
For the purpose of the CI testing, let's use the fork [1] from upstream
XTF with implemented support for arm64 (the upstream XTF only supports
x86).
Add a new script under automation/scripts to be used by the CI XTF test
jobs to perform the following tasks:
- Compiling XTF,
- Generating u-boot script using ImageBuilder,
- Running Xen with XTF as domU in pure dom0less configuration using Qemu,
- Checking test result.
The script takes the name of the XTF test to run as a first parameter.
[1] https://gitlab.com/xen-project/fusa/xtf.git (branch xtf-arm)
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Populate test jobs for Yocto based tests using the provided containers.
Due to the size restrictions, it is currently not possible to split the
build and run tasks, therefore everything is done in a single step.
Test jobs for the supported Yocto targets are generic to avoid the
necessity to add new ones after each Yocto release. The only thing
required to be changed after updating the containers is the variable
YOCTO_VERSION stored in a .yocto-test template.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add make clean support to remove the containers from the local docker
registry.
make clean-<image_name> must be called to remove an image:
make clean-yocto/kirkstone-qemuarm: remove yocto kirkstone for qemuarm
image
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Add containers suitable to run yocto kirkstone build based on ubuntu
22.04. It contains all packages required by Yocto and a checkout of the
layers required to build Xen with Yocto.
Add a generic docker image template to be used to automatically generate
docker files for different configurations:
- specific yocto version
- different targets (qemu arm, arm64 and x86)
- different host platforms (x86 or arm64)
During a call to 'make all', only the images for the host platform we
run it on in the CI is generated.
If needed, images for an other host platform can be generated manually
by calling the right make target (see make help).
Add a build script to build and run xen on qemu using Yocto.
The script supports arm32, arm64 and x86_64 and checks that dom0 is
properly booting. At this stage this does not run any guest on top of
dom0. The script is to be executed in one of the docker images to build
and run a system using a Xen source tree.
Add automation/build/yocto/*.dockerfile to gitignore as those files are
generated.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Now, when these packages are already installed in the respective
containers, we can remove them from the test scripts.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Installation of additional packages from the test scripts when running
the tests has some drawbacks. It is slower than cloning containers and can
fail due to some network issues (apparently it often happens on x86
rackspace). This patch is adding the packages required by the tests to be
installed when building the containers.
>From qemu-alpine-x86_64.sh into debian:stretch:
- cpio,
- busybox-static.
>From qemu-smoke-*-{arm,arm64}.sh into debian:unstable-arm64v8:
- u-boot-qemu,
- u-boot-tools,
- device-tree-compiler,
- curl,
- cpio,
- busybox-static.
The follow-up patch will remove installation of these packages from the
test scripts. This is done in order not to break the CI in-between.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
At the moment, we define lots of test jobs in test.yaml, that make use
of the same configuration sections like variables, tags, artifacts.
Introduce templates (hidden jobs whose names start with a dot) to
reduce the overhead and simplify the file (more than 100 lines saved).
This way, the actual jobs can only specify sections that are unique
to them.
Most of the test jobs specify the same set of prerequisite jobs under
needs property with just one additional being unique to the job itself.
Introduce YAML anchors for that purpose, because when using extends, the
needs property is not being merged (the parent property overwrites the
child one).
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
After qemu arm64 test scripts had been renamed to reflect their
usage, do the same for the qemu arm32 test script. Currently it only
boots dom0, so we can assume that this script will be used to perform
dom0 based testing. In the future we will be able to create corresponding
script qemu-smoke-dom0less-arm32.sh to perform dom0less based testing.
This is the last step to get rid of ambiguity with regards to naming
of Arm test scripts.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
qemu-alpine-arm64.sh script is used to perform dom0 based testing.
Rename this script to qemu-smoke-dom0-arm64.sh to reflect its usage.
Also rename the corresponding test jobs.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Testing arm64 is done using the qemu-alpine-arm64.sh and
qemu-smoke-arm64.sh scripts. These scripts are executed with exactly
the same artifacts (container, rootfs, kernel, qemu) and the only
difference is that the former is used to perform dom0 based testing
and the latter - dom0less based testing.
Because the current naming is quite ambiguous, rename qemu-smoke-arm64.sh
script to qemu-smoke-dom0less-arm64.sh to reflect its usage.
qemu-alpine-arm64.sh will be renamed in the follow-up patch.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Perform the following cleanup:
- rename the device tree from virt-gicv3 to virt-gicv2 as the GIC version
used in this test is v2,
- use fdtput to perform modifications on the dtb,
- use DEBIAN_FRONTEND=noninteractive to prevent interactive prompt being
stuck waiting for answer other than "yes",
- fix the number of cpus in the device tree because currently we generate
it with a single cpu and try to run QEMU with two,
- fix the memory size we pass when generating QEMU device tree as it does
not match the memory size with what we run QEMU.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Take an example from arm64 qemu test scripts and use ImageBuilder
to generate u-boot script automatically. Calculating the addresses
manually is quite error prone and also we will be able to benefit
from using ImageBuilder when adding domUs to this test in the future.
Install and use u-boot from the debian package.
Modify the script so that binaries are loaded from u-boot via tftp.
Remove dtuart=/pl011@9000000 because stdout-path in QEMU dtb is always
set to pl011 node path.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Script automation/scripts/containerize makes it easy to build Xen within
predefined containers from gitlab container registry. This script is
currently missing the helpers to select Arm containers, so populate the
necessary entries.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
At the moment, all the tests are executed on non-debug Xen builds.
To improve the coverage (e.g. we might catch some asserts), add new
test jobs using debug Xen builds.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
In the follow-up patch we will add new jobs using debug Xen builds.
Because the debug builds take more space and we might end up in
a situation when there is not enough free space (especially during
a static memory test that reserves some region in the middle), increase
RAM size for QEMU from 1GB to 2GB.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
For arm64 we perform builds using debian and alpine containers.
We are missing the randconfig build jobs for the latter, so add them.
This way for each container we have 4 fundamental build jobs:
- defconfig non-debug/debug
- randconfig non-debug/debug
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
All the build jobs exist in two flavors: debug and non-debug, where the
former sets 'debug' variable to 'y' and the latter to 'n'. This variable
is only being recognized by the toolstack, because Xen requires
enabling/disabling debug build via e.g. menuconfig/config file.
As a corollary, we end up building/testing Xen with CONFIG_DEBUG always
set to a default value ('y' for unstable and 'n' for stable branches),
regardless of the type of the build job.
Fix this behavior by setting CONFIG_DEBUG according to the 'debug' value.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
NULL scheduler is not enabled by default on non-debug Xen builds. This
causes the boot time cpupools test to fail on such build jobs. Fix the issue
by explicitly specifying the config options required to enable the NULL
scheduler.
Fixes: 36e3f41587 ("automation: Add a new job for testing boot time cpupools on arm64")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
buster-gcc-ibt is a dedicated test to run a not-yet-upstreamed compiler patch
which is relevant to CONFIG_XEN_IBT in 4.17 and later.
Force it on, rather than having 50% of the jobs not testing what they're
supposed to be testing.
Fixes: 5d59421815 ("x86: Use control flow typechecking where possible")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
[stefano: minor code style improvement]
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Currently, all the arm64 defconfig build jobs, regardless of the
container used, end up building Xen with the extra config options
specified in the main build script (e.g. CONFIG_EXPERT,
CONFIG_STATIC_MEMORY). Because these options are only needed for
specific test jobs, the current behavior of the CI is incorrect
as we add the extra options to all the defconfig builds. This means
that on arm64 there is not a single job performing proper defconfig build.
To fix this issue, add custom build jobs each time there is a need for
building Xen with additional config options. Introduce EXTRA_XEN_CONFIG
variable to be used by these jobs to store the required options. This
variable will be then read by the main build script to modify the .config
file. This will also help users to understand what is needed to run specific
test.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add a new test job qemu-smoke-arm64-gcc-boot-cpupools that will execute
script qemu-smoke-arm64.sh to test boot time cpupools feature.
Enable CONFIG_BOOT_TIME_CPUPOOLS for the arm64 build and add a new test
case in qemu-smoke-arm64.sh that if selected will make use of the
ImageBuilder feature to create cpupool with cpu@1, null scheduler and
assign it to domU. Add a check in dom0 xen.start to see if domU is
assigned a Pool-1 with null scheduler.
Take the opportunity to refactor the qemu-smoke-arm64.sh script as
follows:
- use domU_check to store the test's commands to be run from domU
- use dom0_check to store the test's commands to be run from dom0
- use fdtput instead of sed to perform dtb modifications
- use more meaningful messages for "passed" variable. This way we can
grep for messages reported either by domU or dom0 and get rid of
assumption that tests can only be run from domU
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
During the ping test, dom1 tries to assign an ip to eth0 in a loop.
Before setting up the network interface by dom0, this results in
printing the following error message several times:
(XEN) DOM1: ifconfig: SIOCSIFADDR: No such device
Silence this by redirecting stderr/stdout to /dev/null as we do not
care about the output and we should not pollute the log file.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Ayan Kumar Halder <ayankuma@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
After qemu-smoke-arm64 was changed to use kernel 5.19 we end up having
two kernel configurations. This is something not needed and maintaining
a single kernel version is always easier. Modify qemu-alpine-arm64-gcc
to use kernel 5.19 and remove kernel 5.9 from tests-artifacts.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Ayan Kumar Halder <ayankuma@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
This patch modified the test in the following way
- Dom0 is booted with an alpine linux rootfs with the xen tools.
- Once Dom0 is booted, it starts xenstored, calls init-dom0less to setup
the xenstore interface for the dom0less Dom1, setups the bridged network
and attaches a pv network interface to Dom1.
- In the meantime, Dom1 in its init script tries to assign an ip to eth0
and ping Dom0,
- If Dom1 manages to ping Dom0, it prints 'passed'.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Use kernel 5.19 to unblock testing dom0less enhanced.
This kernel version has the necessary patches for deferring xenbus probe
until xenstore is fully initialized.
Also, build kernel with bridging and xen netback support enabled because
it will be used for testing network connectivity between Dom0 and Dom1
over a pv network interface.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Disable xen,enhanced because we don't use PV drivers in this test and
also because the kernel used for testing is old and unpatched and would
break if xen,enhanced is passed.
This patch unbreaks gitlab-ci.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Ayan Kumar Halder <ayankuma@amd.com>
Tested-by: Ayan Kumar Halder <ayankuma@amd.com>
Qemu VM is configured with 2 cpus but the device tree passed has only 1.
Generate a device tree with 2 cpus.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Rename the device tree from virt-gicv3 to virt-gicv2 to avoid confusion
since the version of the generic interrupt controller used for this test
is the v2 and not the v3.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Remove comment "# Install QEMU" because qemu is not installed, it is taken
from a test-artifacts container.
Change comment "# Busybox Dom0" to "# Busybox" because busybox is not used
only for the Dom0 but also for the DomU.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Enable CONFIG_STATIC_MEMORY in the existing arm64 build.
Create a new test job, called qemu-smoke-arm64-gcc-staticmem.
Adjust qemu-smoke-arm64.sh script to accomodate the static memory test as a
new test variant. The test variant is determined based on the first argument
passed to the script. For testing static memory, the argument is 'static-mem'.
The test configures DOM1 with a static memory region and adds a check in the
init script.
The check consists in comparing the contents of the /proc/device-tree
memory entry with the static memory range with which DOM1 was configured.
If the memory layout is correct, a message gets printed by DOM1.
At the end of the qemu run, the script searches for the specific message
in the logs and fails if not found.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Penny Zheng <penny.zheng@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The EXPERT config option cannot anymore be selected via the environmental
variable XEN_CONFIG_EXPERT. Remove stale references to XEN_CONFIG_EXPERT
from the automation code.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Like with "dependencies", the jobs will get artifacts from the jobs
listed in "needs". But the test jobs can run as soon as the build jobs
listed have finished.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The name of the field doesn't matter because it's use as a YAML achor,
but it's nicer to have the proper spelling.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
the test-artifacts qemu container. The minimal test simply boots Xen
(built from previous build stages) and Dom0.
The test needs a working kernel and minimal initrd for dom0. Instead of
building our own kernel and initrd, which would mean maintaining one or
two more builting scripts under automation/, we borrow a kernel and
initrd from distros.
For the kernel we pick the Debian Bullseye kernel, which has everything
we need already built-in. However, we cannot use the Debian Bullseye
initrd because it is 22MB and the large size causes QEMU to core dump.
Instead, use the tiny busybox-based rootfs provided by Alpine Linux,
which is really minimal: just 2.5MB. Note that we cannot use the Alpine
Linux kernel because that doesn't boot on Xen.
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
Reviewed-by: Michal Orzel <michal.orzel@arm.com>
Add qemu-system-arm to the existing test-artifacts qemu container (which
doesn't get build for every iteration but only updated once in a while.)
With qemu-system-arm available, we'll be able to run ARM32 tests.
This patch also bumps the QEMU version to v6.0.0 for both arm32 and
arm64 (the test-artifacts container is one, shared for both).
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Now all indirect branch targets have been annotated, turn on typechecking to
catch issues in the future.
This extension isn't in a released version of GCC yet, so provide a container
to use with the extension included, and add it to CI. RANDCONFIG is necessary
because some stubs for compiled-out subsystems are used as function pointer
targets.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Oleksii Kurochko
Andrew Cooper
Michal Orzel
Bertrand Marquis
Anthony PERARD
Xenia Ragiadakou
Stefano Stabellini
Stefano Stabellini