This should give a lot more useful information in case of a failure, and
also enable some asserts for extra checks.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* Update from GCC 11.2 to 11.3
* Use python3-minimal instead of python
* Use --no-install-recommends, requiring ca-certificates, g++-multilib and
build-essential to be listed explicitly
The resulting container is ~50M smaller
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
For similar reasons to c/s a6b1e2b80f. While this container is still
build-able for now, all the other problems with explicitly-versioned compilers
remain.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This is a first test using Qubes OS CI infra. The gitlab-runner has
access to ssh-based control interface (control@thor.testnet, ssh key
exposed to the test via ssh-agent) and pre-configured HTTP dir for boot
files (mapped under /scratch/gitlab-runner/tftp inside the container).
Details about the setup are described on
https://www.qubes-os.org/news/2022/05/05/automated-os-testing-on-physical-laptops/
There are two test. First is a simple dom0+domU boot smoke test, similar
to other existing tests. The second is one boots Xen, and try if S3
works. It runs on a ADL-based desktop system. The test script is based
on the Xilinx one.
The machine needs newer kernel than other x86 tests run, so use 6.1.x
kernel added in previous commit.
The usage of fakeroot is necessary to preserve device nodes (/dev/null
etc) when repacking rootfs. The test runs in a rootless podman
container, which doesn't have full root permissions. BTW the same
applies to docker with user namespaces enabled (but it's only opt-in
feature there).
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
It will be used in tests added in subsequent patches.
Enable config options needed for those tests.
While at it, migrate all the x86 tests to the newer kernel, and
introduce x86-64-test-needs to allow deduplication later (for now it's
used only once).
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Obtaining code over an insecure transport is a terrible idea for
blatently obvious reasons. Even for non-executable data, insecure
transports are considered deprecated.
This patch enforces the use of secure transports in misc places.
All URLs are known to work.
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Create 2 new test jobs, called qemu-smoke-dom0less-arm64-gcc-static-shared-mem
and qemu-smoke-dom0less-arm64-gcc-debug-static-shared-mem.
Adjust qemu-smoke-dom0less-arm64.sh script to accomodate the static
shared memory test as a new test variant. The test variant is determined
based on the first argument passed to the script. For testing static
shared memory, the argument is 'static-shared-mem'.
The test configures two dom0less DOMUs with a static shared memory
region and adds a check in the init script.
The check consists in comparing the contents of the /proc/device-tree/reserved-memory
xen-shmem entry with the static shared memory range and id with which
DOMUs were configured. If the memory layout is correct, a message gets
printed by DOMU.
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: Jiamei Xie <jiamei.xie@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Create 2 new test jobs, called qemu-smoke-dom0less-arm64-gcc-staticheap
and qemu-smoke-dom0less-arm64-gcc-debug-staticheap.
Add property "xen,static-heap" under /chosen node to enable static-heap.
If the domU can start successfully with static-heap enabled, then this
test pass.
ImageBuillder sets the kernel and ramdisk range based on the file size.
It will use the memory range between 0x45600000 to 0x47AED1E8. It uses
MEMORY_START and MEMORY_END from the cfg file as a range in which it can
instruct u-boot where to place the images.
Change MEMORY_END to 0x50000000 for all test cases.
Signed-off-by: Jiamei Xie <jiamei.xie@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The test prepares dom0 and domU binaries and boot artifacts, similarly
to the existing QEMU test. (TBD: share preparation steps with the
regular QEMU tests.)
However, instead of running the test inside QEMU as usual, it copies
the binaries to the tftp server root, triggers a Xilinx ZCU102 board
reboot, and connects to the real serial of the board.
Only run the job on protected branches with XILINX_JOBS set to true (the
"master" and "staging" on gitlab.com/xen-project/xen qualify).
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
This container is only run on the controller PC (x86) to trigger the
test on a connected Xilinx ZCU102 physical board.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Add missing aliases for:
- debian:unstable-cppcheck
- debian:unstable-arm64v8-arm32-gcc
- ubuntu:bionic
Remove aliases for no longer used containers:
- centos:7.2
- debian:unstable-arm32-gcc
Modify docs to refer to CentOS 7 instead of 7.2 not to create confusion.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Base image "archlinux/base" isn't available anymore,
https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030181.html
But instead of switching to archlinux/archlinux, we will use the
official image from Docker. Main difference is that the first one is
updated daily while the second is updated weekly.
Also, as we will install the packages from "base-devel" anyway, switch
to the "base-devel" tag.
"dev86" package is now available from the main repo, no need for
multilib repo anymore.
It is recommended to initialise local signing key used by pacman, so
let's do that.
Replace "markdown" by "discount" as the former isn't available anymore
and has been replaced by the later.
Also, clean pacman's cache.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Ask docker to check if there's an update of the base image to avoid
using an old container cached locally.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add a debian container with cppcheck installation routine inside,
capable of performing cppcheck analysis on Xen-only build including
cross-builds for arm32 and x86_64.
Populate build jobs making use of that container to run cppcheck
analysis to produce a text report (xen-cppcheck.txt) containing the list
of all the findings.
This patch does not aim at performing any sort of bisection. Cppcheck is
imperfect and for now, our goal is to at least be aware of its reports,
so that we can compare them with the ones produced by better tools and
to be able to see how these reports change as a result of further
infrastructure improvements (e.g. exception list, rules exclusion).
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
As part of the arm32 dom0 test, also create a simple domU using xl. To
do that, we need the toolstack installed in the dom0 rootfs. We switch
to using the kernel and rootfs built by the Yocto arm32 job.
Remove the PCI node from the host device tree: it is unused but causes a
Linux hang at boot.
Use xen-watchdog to trigger the domU creation for convience
(/etc/local.d is not handled by rootfs.)
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Copy the build output of Yocto builds to binaries/ for the arm32 target,
and export binaries/ among the jobs artifacts so that they can be reused
by other jobs.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
We are going to use artifacts produced by the Yocto builds in test jobs.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Use a single fairly generic string as the "all done" message to look for,
which avoids the need to patch qemu-smoke-riscv64.sh each time a new feature
is added.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In the interest of having less jobs, we remove the x86_32 build jobs
that do release build. Debug build is very likely to be enough to find
32bit build issues.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
While the Let's Encrypt root certificate ISRG_Root_X1.crt is already
present, openssl seems to still check for the root certificate
DST_Root_CA_X3.crt which has expired. This prevent https connections.
Removing DST_Root_CA_X3 fix the issue.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jessie as rearch EOL in 2020.
Even if we update the containers, we would still not be able to reach
HTTPS webside with Let's Encrypt certificates and thus would need more
change to the container.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
As Jessie is EOL, the official tag isn't supported anymore. Also, the
GPG key for the packages on the repository on the official image are
expired and it isn't possible to update or install packages.
But we can use the image from "debian/eol" tag which use repositories
from archive.debian.org and have workaround to ignore the validity
date of the keys.
There isn't a dedicated i386 tag for jessie, but we can ask docker to
pull the i386 image of the "debial/eol:jessie" tag.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
First, apt complain that it isn't the right way to add keys anymore,
but hopefully that's just a warning.
Second, we can't install clang-8:
The following packages have unmet dependencies:
clang-8 : Depends: libstdc++-8-dev but it is not installable
Depends: libgcc-8-dev but it is not installable
Depends: libobjc-8-dev but it is not installable
Recommends: llvm-8-dev but it is not going to be installed
Recommends: libomp-8-dev but it is not going to be installed
libllvm8 : Depends: libffi7 (>= 3.3~20180313) but it is not installable
E: Unable to correct problems, you have held broken packages.
clang on Debian unstable is now version 14.0.6.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
We already have a container which track the latest CentOS 7, no need
for this one as well.
Also, 7.2 have outdated root certificate which prevent connection to
website which use Let's Encrypt.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add a new test job qemu-smoke-dom0less-arm32-gcc-without-dom0 in debug
and non-debug variant that will execute qemu-smoke-dom0less-arm32.sh
script to test dom0less domU boot without dom0 (i.e. true dom0less
configuration).
By passing "without-dom0" as a test variant, the test will clear the
dom0 prompt that we grep for as a last step and remove all the DOM0
related options in ImageBuilder configuration.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Xen supports booting gzip compressed kernels, therefore add a new test
job qemu-smoke-dom0less-arm32-gcc-gzip in debug and non-debug variant
that will execute qemu-smoke-dom0less-arm32.sh script to test booting
a domU with a gzip compressed kernel image (in our case zImage).
By passing "gzip" as a test variant, the test will call gzip command
to compress kernel image and use it in ImageBuilder configuration for
domU1. No need for a specific check to be executed from domU. Being able
to see a test message from a boot log is sufficient to mark a test as
passed.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add a new test job qemu-smoke-dom0less-arm32-gcc-staticmem in debug
and non-debug variant that will execute qemu-smoke-dom0less-arm32.sh
script to test static memory allocation feature. The test case itself
is directly taken from dom0less arm64 testing.
Populate build jobs to compile Xen with config options necessary to
enable static memory feature. Populate test jobs passing "static-mem"
as a test variant. The test configures domU with a static memory region
(direct-mapped) and adds a check using /proc/iomem to determine the
memory region marked as "System RAM".
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
At the moment, we only perform a single arm32 test in our CI, checking
whether dom0 boots successfully or not. This is mostly because we do not
have any arm32 runners and we only execute a hypervisor only build.
In order not to leave the arm32 testing in such a poor state, add a
script qemu-smoke-dom0less-arm32.sh to start testing dom0less
configuration, while keeping dom0 to make the test more interesting.
The script is mostly based on the one used for dom0 arm32 testing as well
as the one used for dom0less arm64 testing. We obtain Debian Bullseye
kernel and Alpine Linux busybox-based rootfs. Depending on the test
variant, we prepare a test case contained within domU_check variable,
that will be executed as part of /init script from domU rootfs.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Due to the limited x86 CI resources slowing down the whole pipeline,
switch the arm32 cross builds to be executed on arm64 which is much more
capable. For that, rename the existing debian container dockerfile
from unstable-arm32-gcc to unstable-arm64v8-arm32-gcc and use
arm64v8/debian:unstable as an image. Note, that we cannot use the same
container name as we have to keep the backwards compatibility.
Take the opportunity to remove extra empty line at the end of a file.
Modify the tag of .arm32-cross-build-tmpl to arm64 and update the build
jobs accordingly.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add check if there is a message 'Hello from C env' presents
in log file to be sure that stack is set and C part of early printk
is working.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
At the moment, the static-mem check relies on the way Xen exposes the
memory banks in device tree. As this might change, the check should be
modified to be generic and not to rely on device tree. In this case,
let's use /proc/iomem which exposes the memory ranges in %08x format
as follows:
<start_addr>-<end_addr> : <description>
This way, we can grep in /proc/iomem for an entry containing memory
region defined by the static-mem configuration with "System RAM"
description. If it exists, mark the test as passed. Also, take the
opportunity to add 0x prefix to domu_{base,size} definition rather than
adding it in front of each occurence.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
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>
Marek Marczykowski-Górecki
Andrew Cooper
Demi Marie Obenour
Jiamei Xie
Michal Orzel
Stefano Stabellini
Anthony PERARD
Oleksii Kurochko
Bertrand Marquis